Currently the Qt Dependencies still use the old "combined" method for
dependencies with multiple ways to be found. This is problematic as it
means that `get_variable()` and friends don't work, as the dependency
can't implement any of those methods. The correct solution is to make
use of multiple Dependency instances, and a factory to tie them
together. This does that.
To handle QMake, I've leveraged the existing config-tool mechanism,
which allows us to save a good deal of code, and use well tested code
instead of rolling more of our own code.
The one thing this doesn't do, but we probably should, is expose the
macOS ExtraFrameworks directly, instead of forcing them to be found
through QMake. That is a problem for another series, and someone who
cares more about macOS than I do.
It's a method on the QtDependeny that exists purely for the consumption
of the qt module (in the form, return some stuff the module makes into
an instance variable). So put it where it actually belongs, and pass the
qt dependency into it.
Dependencies is already a large and complicated package without adding
programs to the list. This also allows us to untangle a bit of spaghetti
that we have.
If a custom_target output is a directory, we install it as a directory,
not as a file. And, we try to track subdirectories which are created so
uninstalling works. But one directory creation did not go through
DirMaker, in the case where the output directory does not have any
further subdirectories.
Consolidate on makedirs, since I don't see much point in using os.mkdir
right here.
This requires quite a complex and messy logic.
As @dcbaker suggested in #8491, this could be replaced by
an abstraction over linker flags instead of having GNU flags
translated.
get_non_matching_default_options is checking a string from
project_default_options against a validated value from
coredata.options.
Passing the string to validate_value ensures that the comparison
is sound; otherwise, "false" might be compared against False
and a bogus difference is printed.
When reverting from 0.57 to 0.56, one can see an error like this:
File /Users/pm215/src/qemu-for-merges/meson/mesonbuild/coredata.py,
line 1016, in load
obj = pickle.load(f)
ModuleNotFoundError: No module named 'mesonbuild.mesonlib.universal';
'mesonbuild.mesonlib' is not a package
FAILED: build.ninja
The reason is that the old version fails to resolve mesonbuild.mesonlib,
which is a similar situation to the existing AttributeError check. Raise
a MesonException for ModuleNotFoundError as well, so that reconfiguration
proceeds using cmd_line.txt.
Previously builds would *potentially* get sammed with messaging at
configure time that duplicate entries in an array would be an error in
the future, and the cause was because the same entries were getting
added over and over to pkg_config_path.p
This is a useful thing to document. I wasn't really sure where to put
it, but since it's developer oriented I figured in the code itself was
probably more useful and more likely to be seen than in the markdown
that generates the website.
The script dir is never really used since meson --internal handles this.
The last remaining use of the raw script dir got removed in commit
522392e755.
In commit caab4d3d, the uid and gid arguments passed to os.chown() by
set_chown() were accidentally swapped, causing files to end up with
incorrect owner/group if the owner and group are not the same.
Also update the documentation to better indicate which argument to
install_mode is which.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Dylan Baker
Eli Schwartz
Xavier Claessens
Remi Thebault
Jussi Pakkanen
Paolo Bonzini
Tristan Partin
Laurin-Luis Lehning
Vili Väinölä
Peter Kjellerstedt
Olexa Bilaniuk