There is nothing to "warn" about, this is a completely routine
occurence. OTOH, when something is corrupted, we should warn. Keep
the red color and "WARNING:" prefix in that case.
Example output:
$ ninja -C build
Regenerating configuration from scratch: Build directory has been generated with Meson version 0.55.999, which is incompatible with current version 0.56.0.
The Meson build system
Version: 0.56.0
...
This creates a full set of option in environment that mirror those in
coredata, this mirroring of the coredata structure is convenient because
lookups int env (such as when initializing compilers) becomes a straight
dict lookup, with no list iteration. It also means that all of the
command line and machine files are read and stored in the correct order
before they're ever accessed, simplifying the logic of using them.
This puts all of them together, in the next patch they'll be pulled back
out, but it's convenient to start that refactor by moving them all
there, then moving them into env as a whole.
This is like the project options, but for meson builtin options.
The only real differences here have to do with the differences between
meson builtin options and project options. Some meson options can be set
on a per-machine basis (build.pkg_config_path vs pkg_config_path) others
can be set on a per-subproject basis, but should inherit the parent
setting.
This allows adding a `[project options]` section to a cross or native file
that contains the options defined for a project in it's meson_option.txt
file.
Some warnings are out of the user's control, such as the RCC QT bug,
or the GNU windres bug, or our informational warning about
auto-disabling of options when -Db_bitcode is enabled.
Such warnings should not be fatal when --fatal-meson-warnings is
passed because there's no action that the user can take to fix it. The
only purpose it serves is to prevent people who use those features
from using --fatal-meson-warnings.
Machine files already supports `+` operator as an implementation detail,
since it's using eval(). Now make it an officially supported feature and
add a way to define constants that are used while evaluating an entry
value.
Generally, we'd want to use str() rather than repr() in error messages
anyhow, as that explicitly gives something designed to be read by
humans.
Sometimes {!r} is being used as a shortcut to avoid writing the quotes
in '{!s}'.
Unfortunately, these things aren't quite the same, as the repr of a
string containing '\' (the path separator on Windows) will have those
escaped.
We don't have a good string representation to use for the arbitrary
internal object used as an argument for install_data() when it's neither
a string nor file (which doesn't lead to a good error message), so drop
that for the moment.
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
It may not be obvious to users that these two ways to set build-types
override each other and specifying both is redundant, and conflicts
are resolved based on whichever is specified later.
Closes https://github.com/mesonbuild/meson/issues/6742
With the current logic passing `--debug` will actually be parsed as
`-Ddebug=false`, which is absolutely not what is expected.
There is no case in which the presence of a boolean option in `--foo`
form will mean 'I want feature foo disabled', regardless of the
*default* value of that option.
Also includes a test.
Closes https://github.com/mesonbuild/meson/issues/4686
The previous code was assuming that options do not depend on each
other, and that you can set defaults using `dict.setdefault()`. This
is not true for `buildtype` + `optimization`/`debug`, so we add
defaults + overrides in the right order and use the options parsing
code later to compute the values.
Includes a test.
Closes https://github.com/mesonbuild/meson/issues/6752
This ensures that options are always parsed in the order in which they
were specified on the command-line, even with Python 3.5, and
non-CPython implementations compatible with CPython 3.5 and 3.6.
Closes https://github.com/mesonbuild/meson/issues/6742
Currently it's just like if all builtin/base/compiler options are
yielding. This patch makes possible to have non-yielding builtin
options. The value in is overriden in this order:
- Value from parent project
- Value from subproject's default_options if set
- Value from subproject() default_options if set
- Value from command line if set
* Extend test_prefix_dependent_defaults unit test to cover default case
Extend test_prefix_dependent_defaults unit test to cover the default
case, when the default prefix is '/usr/local'. (On Windows, the default
prefix is 'c:/')
* Restore adjusting option defaults depending on the default prefix
Restore adjusting option defaults, depending on the default prefix.
Droppped in d778a371
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll
get ld.gold, not whatever the default is. Meson currently doesn't do
that, because it doesn't pass these arguments to the linker detection
logic. This patch fixes that. Another case that this is needed is with
clang's --target option
This is a bad solution, honestly, and it would be better to use $LD or a
cross/native file but this is needed for backwards compatability.
Fixes#6057
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
Otherwise having an output directory matching the name of the cross file
in the current working directory will cause an error. This patch instead
collects any invalid names and prints them along with the error message
when no valid file can be found.
Fixes#5640
This is used in a lot of places, having a single way to reference it is
convenient. It's placed under a typing.TYPE_CHECKING guard to mimimize
runtime impact
* coredata: Correctly handle receiving a pipe for native/cross files
In some cases a cross/native file may be a pipe, such as when using bash
process replacement `meson --native-file
<([binaries]llvm-config='/opt/bin/llvm-config')`, for example. In this
case we copy the contents of the pipe into a file in the meson-private
directory so we can create a proper ninja dependency, and be able to
reload the file on --wipe/--reconfigure. This requires some extra
negotiation to preserve these native/cross files.
Fixes#5505
* run_unitests: Add a unit test for native files that are pipes
Using mkfifo.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
Handling the PKG_CONFIG_PATH variable in meson introduces a new problem
for caching dependencies. We want to encode the pkg_config_path (or
cross_pkg_config_path if we're cross compiling) to be part of the key,
but we don't want to put that into the key for non-pkg-config
dependencies to avoid spurious cache misses (since pkg_config_path isn't
relevant to cmake, for example). However, on a cache lookup we can't
know that a dependency is a pkg-config dependency until we've looked in
the cache.
My solution is a two layer cache, the first layer remains the same as
before, the second layer is a dict-like object that encapsulates the
dependency type information and uses pkg_config_path and
cross_pkg_config_path as a sub key (and could be extended easily for
other types). A new object type is introduced to encapsulate this so
that callers don't need to be aware of the implementation details.
There are two distinct bugs here:
1) if PKG_CONFIG_PATH is unset then the variable will be set to [''],
which causes it to have the wrong behavior in some truthiness tests
2) We read PKG_CONFIG_PATH on invocations after the first, which causes
it to overwrite the value saved into the coredata.dat file. Putting
the two bugs together it means that -Dpkg_config_path doesn't work
with `meson configure`
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
Some things, like `method[...](...)` or `x: ... = ...` python 3.5
doesn't support, so I made a comment instead with the intention that it
can someday be made into a real annotation.
* coredata: store cross/native files in the same form they will be used
Currently they're forced to absolute paths when they're stored in the
coredata datastructure, then when they're loaded we de-absolute path
them to check if they're in the system wide directories. This doesn't
work at all, since the ninja backend will generat a dependency on a
file that is in the source directory unless the path was already given
as absolute. This results in builds being retriggereed forever due to
a non-existant file.
The right way to do this is to figure out whether the file is in the
build directory, is absolute, or is in one of the system paths at
creation time, and store that path as absolute. Then the code that
reads the file and the code that generates the dependencies in the
ninja backend just takes the computed list and there is no mismatch
between them.
Fixes#5257
* run_unittests: Add a test for correct native file storage
This tests the bug in #5257
Currently this only marks the pkg_config_path flag, but it could be
used to mark any of these values as having separate values for cross
and native builds, assuming that the necessary plumbing is done.
This creates a new command line option to store pkg_config_path into,
and store the environment variable into that option. Currently this
works like the environment variable, for both cross and native targets.
Daniel Mensinger