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
Dylan Baker
Xavier Claessens
Jussi Pakkanen
Jon Turney
Daniel Mensinger
Michael Hirsch, Ph.D
Michael Hirsch, Ph.D
Paulo Neves
Wolfgang Stöggl
Olexa Bilaniuk
Aleksey Gurtovoy
Clinton Roy
John Ericson
John Ericson
TheQwertiest