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.
This returns a list out of th keys of a dict. In both cases of use
remaining though it's used for checking membership, checking for list
membership, lists are O(n) lookup, while dicts are O(1), so removing
the abstraction reduces typing and improves performance.
Currently the builtins are stored as lists, then there are a mess of
functions which take said lists, check what the type of the first
thing is, and then extract data from various points in the list based
on that.
This is stupid. This is what structs/classes are for.
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
Instead of hard-coding the fact that load_configs() searches for files under
meson/native, pass in the subdirectory allowing the cross-file code to use the
same logic.
Before, the logic initialization compiler options from environment
variables vs config files was strewn about. Now, it is consolidated. We
leverage the new `envconfig.py` module to expose the configuration data
to `compilers.py` without creating an import cycle.
'c_arg' entries should become *both* compiler options and external
peprocessor options for C. (And likewise for a few other languages.)
Seems inconsistent to me, but this is the status quo.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
Fixes this annoying warning while running the tests:
mesonbuild/coredata.py:237: DeprecationWarning: The SafeConfigParser
class has been renamed to ConfigParser in Python 3.2. This alias will be
removed in future versions. Use ConfigParser directly instead.
Our builddir ABI is stable across minor (stable) releases, so there is
no need to force a wipe. We already release pretty often, no need to
force people to wipe twice as often.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
Dylan Baker
Michael Hirsch, Ph.D
Jussi Pakkanen
John Ericson
John Ericson
Daniel Mensinger
TheQwertiest
Ross Burton
jml1795
Nirbheek Chauhan
Nicolas Schneider