This is just a bad warning, while it *could* give the user useful
information, it often doesn't since it can get values to warn about
from:
- environment variables
- the command line
- machine files
- `project(default_options : ...)`
- `subproject(default_options : ...)`
- `dependency(default_options : ...)`
The problem of course is that user may have no control over these
values. 3 of them are hardcoded into the meson.build files, so the user
can't do anything about them. And there are legitimate reasons to have
unused values in those, like setting defaults for a language only used
on specific platforms.
Environment variables may be set by the distro (NixOS sets them for any
enabled language, so just having a D compiler causes `DFLAGS` to be set,
for example). They likely don't want to special case "only set the
environment variables if the project is going to use them".
For machine files it limits the utility of the files, since the user
needs to be sure that they don't include any options that wont be used.
Finally, the command line could be altered by wrapper scripts, or simply
programmed to insert options that *may* be used but aren't required.
like setting `objc_args` regardless of whether ObjectivC bindings are
generated.
However, passing completely unknown builtin options should be an error,
as it was before the optionrefactor
"PEP 667: Consistent views of namespaces" caused locals() to be
inconsistent between uses since it is now created afresh every time you
invoke it and writes to it are dropped. `sys._getframe().f_locals` is
equivalent but preserves writes (it doesn't create a new dict) and
unfortunately doesn't help at all as it's documented to be a private
implementation detail of CPython that "should be used for internal and
specialized purposes only".
Work around this by saving locals to a variable reference and both
passing it into runctx and reusing it in lookups of the result. This
works okay for both new and older versions of python.
Per the documentation for locals():
> The contents of this dictionary should not be modified; changes may
> not affect the values of local and free variables used by the
> interpreter.
So... lesson learned? :) This was introduced in commit
c34ee374a77fb2dffff90364506ac0cbbb1f00de; before that, we still used
locals() but only to pass local variables *in*.
Bug: https://github.com/python/cpython/pull/115153
These are much easier to handle as one commit since msetup calls mconf
internally. This has found one case where things are being carefully
crafted to work in mconf even though msetup has slightly different
options
Anywhere we have that, we also have the Environment object, which is
just wrapped by the Interpreter methods anyway. This avoids inderections
that are unnecessary.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
`meson setup -Dfoo=bar builddir` command was returning success ignoring
new option values.
This now also update options. It is useful because it means
`meson setup -Dfoo=bar builddir && ninja -C builddir` works regardless
whether builddir already exists or not, and when done in a script,
changing options in the script will automatically trigger a reconfigure
if needed. This was already possible by always passing --reconfigure
argument, but that triggers a reconfigure even when options did not
change.
When running setup with `--profile-self` option,
there are currently no logs after "Found ninja...". However, there are
still some lengthy processes for generating targets and ninja.build.
This add more log entries, when profiling, only for the purpose of
displaying the timestamps of the different steps in ninja generation.
After the recent change to the backend `generate(...)` signature for
'--genvslite', `profile.runctx('...')` needs to construct the correct
cmd string and also extract the return result from `locals()`.
By avoiding Java-style variable naming, the code becomes considerably
more readable while simultaneously becoming *more* easy to understand.
It's no longer necessary to ask questions like "what's a captured
buildtype" when trying to read through the code for a backend, because
it can be dismissed as not relevant to the current context by re-reading
it as "context for vslite".
The primary goal here has been to revert regressions in the developer
experience for users of the ninja backend, so there may still be issues
in vs2010backend.py
Post-facto application of issues that were raised during review,
ignored, and merged despite such.
Function comments that overflow the screen width by coming after code,
instead of on their own line, are hard to read. Same applies to message
strings that are all on one line. Fix by reflowing them.
Post-facto application of issues that were caught during post-merge
review, after the genvslite PR was merged without a full review.
* Capture all compile args from the first round of ninja backend generation for all languages used in building the targets so that these args, defines, and include paths can be applied to the .vcxproj's intellisense fields for all buildtypes/configurations.
Solution generation is now set up for mutiple build configurations (buildtypes) when using '--genvslite'.
All generated vcxprojs invoke the same high-level meson compile to build all targets; there's no selective target building (could add this later). Related to this, we skip pointlessly generating vcxprojs for targets that aren't buildable (BuildTarget-derived), which aren't of interest to the user anyway.
When using --genvslite, no longer inject '<ProjectReference ...>' dependencies on which a generated .vcxproj depends because that imposes a forced visual studio build dependency, which we don't want, since we're essentially bypassing VS's build in favour of running 'meson compile ...'.
When populating the vcxproj's shared intellisense defines, include paths, and compiler options fields, we choose the most frequent src file language, since this means more project src files can simply reference the project shared fields and fewer files of non-primary language types need to populate their full set of intellisense fields. This makes for smaller .vcxproj files.
Paths for generated source/header/etc files, left alone, would be added to solution projects relative to the '..._vs' build directory, where they're never generated; they're generated under the respective '..._[debug/opt/release]' ninja build directories that correspond to the solution build configuration. Although VS doesn't allow conditional src/header listings in vcxprojs (at least not in a simple way that I'm aware of), we can ensure these generated sources get adjusted to at least reference locations under one of the concrete build directories (I've chosen '..._debug') under which they will be generated.
Testing with --genvslite has revealed that, in some cases, the presence of 'c:\windows\system32;c:\windows' on the 'Path' environment variable (via the make-style project's ExecutablePath element) is critical to getting the 'meson compile ...' build to succeed. Not sure whether this is some 'find and guess' implicit defaults behaviour within meson or within the MSVC compiler that some projects may rely on. Feels weird but not sure of a better solution than forcibly adding these to the Path environment variable (the Executable Path property of the project).
Added a new windows-only test to windowstests.py ('test_genvslite') to exercise the --genvslite option along with checking that the 'msbuild' command invokes the 'meson compile ...' of the build-type-appropriate-suffixed temporary build dir and checks expected program output.
Check and report error if user specifies a non-ninja backend with a 'genvslite' setup, since that conflicts with the stated behaviour of genvslite. Also added this test case to 'WindowsTests.test_genvslite'
I had problems tracking down some problematic environment variable behaviour, which appears to need a work-around. See further notes on VSINSTALLDIR, in windowstests.py, test_genvslite.
'meson setup --help' clearly states that positional arguments are ... [builddir] [sourcedir]. However, BasePlatformTests.init(...) was passing these in the order [sourcedir] [builddir]. This was producing failures, saying, "ERROR: Neither directory contains a build file meson.build." but when using the correct ordering, setup now succeeds.
Changed regen, run_tests, and run_install utility projects to be simpler makefile projects instead, with commands to invoke the appropriate '...meson.py --internal regencheck ...' (or install/test) on the '[builddir]_[buildtype]' as appropriate for the curent VS configuration. Also, since the 'regen.vcxproj' utility didn't work correctly with '--genvslite' setup build dirs, and getting it to fully work would require more non-trivial intrusion into new parts of meson (i.e. '--internal regencheck', '--internal regenerate', and perhaps also 'setup --reconfigure'), for now, the REGEN project is replaced with a simpler, lighter-weight RECONFIGURE utility proj, which is unlinked from any solution build dependencies and which simply runs 'meson setup --reconfigure [builddir]_[buildtype] [srcdir]' on each of the ninja-backend build dirs for each buildtype.
Yes, although this will enable the building/compiling to be correctly configured, it can leave the solution/vcxprojs stale and out-of-date, it's simple for the user to 'meson setup --genvslite ...' to fully regenerate an updated, correct solution again. However, I've noted this down as a 'fixme' to consider implementing the full regen behaviour for the genvslite case.
* Review feedback changes -
- Avoid use of 'captured_compile_args_per_buildtype_and_target' as an 'out' param.
- Factored a little msetup.py, 'run(...)' macro/looping setup steps, for genvslite, out into a 'run_genvslite_setup' func.
* Review feedback: Fixed missing spaces between multi-line strings.
* 'backend_name' assignment gets immediately overwritten in 'genvslite' case so moved it into else/non-genvslite block.
* Had to bump up 'test cases/unit/113 genvslites/...' up to 114; it collided with a newly added test dir again.
* Changed validation of 'capture' and 'captured_compile_args_...' to use MesonBugException instead of MesonException.
* Changed some function param and closing brace indentation.
msetup.py doesn't need to know the gory details of PkgConfigDependency,
or directly import it at program startup. It's also slightly wasteful to
generate a devenv for the -uninstalled directory when a project doesn't
even, in the end, use the pkgconfig module anyway.
We may want to do things like update install scripts as well, which have
to happen before generating the backend. Instead of adding one module
method per thing to do, use a single function that allows for modifying
the Build object directly.
Also prevent from using a parent directory as builddir by mistake.
Co-authored-by: Volker Weißmann <volker.weissmann@gmx.de>
Co-authored-by: Charles Brunet <charles.brunet@optelgroup.com>
- MesonException for errors is clearer than SystemExit('error message')
and provides meson-formatted "ERROR: ..."
- `raise SystemExit` with no parameter isn't obvious that it intends to
exit successfully
While clarifying the latter, it was observed to cause
test_preprocessor_checks_CPPFLAGS() failure to be ignored. That test
checks get_define() on both c and cpp compilers, which means we need to
define either CPPFLAGS or both CFLAGS+CXXFLAGS.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
This allows to run setup command regardless whether the builddir has
been configured or not previously. This is useful for example with
scripts that always repeat all options.
meson setup builddir --reconfigure -Dfoo=bar
This can happen from typos, which then confusingly claim that neither
build directory has a meson.build file because the implicit . directory
was not actually one of the directories. Instead a random command line
argument was interpreted as a directory name.
Fixes#11472
mypy is pretty dumb when it comes to unions of callables (pylance is
also dumb in this regard), and can't figure out that our use of
`mlog.debug | mlog.log` is perfectly safe. We also can't annotate them
properly to cast them to a valid subset of arguments because you can't
have splats in `typing.Callable`, so I've done enough to make it work.
The one case of this was a false-positive, but what we were doing
(checking locals()) is not idiomatic. I've replaced the call to
`locals()` with the obvious `var: T.Optional[str] = None` with check
instead.
We want to optimize out some internal codepaths used at build time by
avoiding work such as argparse. This doesn't work particularly well when
the argparse arguments are imported before then. Between them, they
indirectly import pretty much all code anywhere, and msetup alone
imports most of it.
Also make sure the regenerate internal script goes directly to msetup.
It's broken in various circumstances, no one seems to actually use it,
CI doesn't test it, no one is committed to maintaining it, etc. etc.
etc.
Also, projects doing trivially reasonable things, such as generating
"foo/util.py" and "bar/util.py", create clashing output names. This will
never, ever, ever, ever work with layout=flat.
Closes#996Closes#1521Closes#1908Closes#7133Closes#7135Closes#7480Closes#8378
Until we invoke interpreter.Interpreter(b, ...) the coredata options
still have their default values and thus cannot be used sensibly.
Currently the warning never shows (other than, unsurprising in
retrospect, during --internal regenerate).
It is a commonly needed information to help debugging build issues. We
already were printing options with non-default value at the end of the
configure but outside of the summary.
Keeping the list of user defined options in the interpreter will also in
the future be useful to use new default value on reconfigure.
This fix issue when using --wipe and the machine file was passed as a
pipe and written locally, or when the file was resolved in XDG_DATA_HOME
or XDG_DATA_DIRS.
Fixes: #8560
Dylan Baker