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.
The option description has a lot of data packed into it, which is
squeezed into a small, hard to read column. Give a bit less information,
focusing on essentials, to make it fit better.
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.
We can check something's subtype using properties, without importing the
module up front and doing isinstance checks on specific subclasses of
the interface -- or worse, solving cyclic imports by doing the import
inside the function. ;)
When a project targets a dev version of Meson (e.g. 1.1.99) for
experimenting, this allows to use:
project(..., meson_version: '>=1.2.0')
It avoids getting warnings when using FeatureNew for features introduced
in 1.2.0.
We actually do not and should not care about wrap-mode at all for this.
We want to cache dependency lookups whenever humanly possible, but only
use them in cases where we would anyways be using them -- which in
particular means if we said to force a subproject fallback for this dep,
we want to bypass the cache.
Currently, we handle this by always looking up the cache for all
dependencies, but clearing the cache at startup if a reconfigure means
we are changing our resolution strategy. This is bad -- we might have
many dependencies that are worth caching, and only one dependency that
should stop being cached and use a subproject instead.
The simple solution is to handle the forcefallback case when doing a
cache lookup, and not do a cache lookup at all. Now we don't have to
nuke the entire cache. In fact, if a future reconfigure changes the
forcefallback state back to not being forced, we can reuse the original
cached dependency, which is still there.
Closes#11828
This option can never have a value of None. There are only two sources
of values at all:
- the class instance initializer when defining BUILTIN_CORE_OPTIONS
- user-provided command-line or machine file values etc. which can only
be meson types
We know we don't construct the Option instance with None, and users
cannot pass a None anywhere since that's not a meson type. The only
reason this was ever checked for was as an artifact during the initial
implementation of the option in commit 8651d55c6a.
At the time, a review comment was made that `-Dinstall_umask=none` was a
bad UX and "preserve" should be used instead. Before that, this option
type accepted `None` (in the BUILTIN_CORE_OPTIONS initializer) and
`'none'` (provided by users) which is odd and should have consistently
been the latter. Then inside set_value, it checked for the magic
initializer value and converted it to the real value.
After review comments and a force-push, the patch ended up using `None`
in the initializer, and `'preserve'` everywhere else, and still handling
both in set_value and converting both to a proper string.
In the very next commit in the patch series, the initializer was
migrated to use an actual umask of 022, and now `None` was entirely
impossible to get anywhere at all. But the wart of checking for it was
never removed. Remove it at long last.
For all source `*.py` files installed via either py.install_sources() or
an `install_dir: py.get_install_dir()`, produce `*.pyc` files at install
time. Controllable via a module option.
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
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
This was added in f774609 to only change the access time of the
coredata file if the coredata struct actually changed. However,
this doesn't work as pickle serializations aren't guaranteed to
be stable. Instead, let's manually check if options have changed
values and skip the save if they haven't changed.
We also extend the associated unit test to cover all the option
types and to ensure that configure does get executed if one of the
options changes value.
It's actually Generic, and we should use Generic annotations to get the
correct result. This means that we don't have to assert or cast the
return type, because mypy just knowns
Caching Compiler.run() seems likely to cause problems, but some users, like
.sizeof(), we know enough about the program run to make it safe.
This commit just adds the Compiler.cached_run(), a subsequent commit makes use
of it.
Instead of setting it to `Optional[bool] = None`, and then in the
initializer replacing `None` with `DEFAULT_YIELDING`, just set to to
`bool = DEFAULT_YIELDING`
When a compiler is initialized, it adds specific options that it
supports, but taking some global UserOption objects and adding them to
itself. When it does so, it mutates then if necessary. This means that
each compiler initialized mutates global state, this is bad. This is
worse because in our test suite we do in process testing, so these
mutations are preserved *between tests*, potentially leading to
incorrect results. The simple fix is to do the right thing, and copy the
UserOption before mutating. A deepcopy is required because the option
might be an ArrayOption, and a shallow copy is not sufficient in that
case.
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
"meson setup" ignores unused compiler options, like "cpp_args" on a project without C++.
"meson configure" doesn't have the filtering from "set_default_options", so it fails with :
ERROR: Unknown options: "cpp_args"
So now unused compiler options (ie not in coredata.options) are no longer marked unknown.
Fixes: #11060
Since commit 1420d0dace we use coredata's
cmd_line.txt handler to get the right setup arguments. But there's a bug
in that -- it mishandles cross/native files, producing invalid
descriptions of the command line. The only other place this was used,
though, is when generating meson-log.txt.
Fix it to produce correctly formatted arguments.
Fixes#10980
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
Tristan Partin
Jussi Pakkanen
Eli Schwartz
GertyP
Xavier Claessens
Volker Weißmann
Josh Soref
Daan De Meyer
Dylan Baker
Andres Freund
X512
David Robillard
Loïc Yhuel
Jan Tojnar