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.
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.
All changes were created by running
"pyupgrade --py3-only --keep-percent-format"
and committing the results. I have not touched string formatting for
now.
- use set literals
- simplify .format() parameter naming
- remove __future__
- remove default "r" mode for open()
- use OSError rather than compatibility aliases
- remove stray parentheses in function(generator) scopes
hdf5's config-tools will not show compile arguments (including the
include directory) if called without `-c`. Make sure to get both the
compile and link arguments.
Currently we use the mesonlib ones, but these are always the build
machine definitions, rather than being available for either the build or
host machine. We already have an `Environment` instance, and the correct
`MachineChoice`, so lets use that.
Fixes#8165
This both moves the env reading to configuration time, which is useful,
and also simplifies the implementation of the boost dependency. The
simplification comes from being able to delete basically duplicated code
since the values will be in the Properties if they exist at all.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
Allow methods on the compiler object to receive internal dependencies,
as long as they only specify compiler/linker arguments or other
dependencies that satisfy the same requirements.
This is useful if you're using internal dependencies to add special
"-D" flags such as -DNCURSES_WIDECHAR, -D_XOPEN_SOURCE_EXTENDED or
-DGLIB_STATIC_COMPILATION.
Some CMake packages fail to find at all if no version is specified.
This commit adds a cmake_version parameter to dependency() to allow you
to specify the requested version.
When finding the Qt compilation tools (moc, uic, rcc, lrelease), the
version strings contain a trailing newline character. This results in a
stray newline in the meson log:
Detecting Qt5 tools
Program /usr/lib64/qt5/bin/moc found: YES 5.14.2
(/usr/lib64/qt5/bin/moc)
Program /usr/lib64/qt5/bin/uic found: YES 5.14.2
(/usr/lib64/qt5/bin/uic)
Program /usr/lib64/qt5/bin/rcc found: YES 5.14.2
(/usr/lib64/qt5/bin/rcc)
Program /usr/lib64/qt5/bin/lrelease found: YES 5.14.2
(/usr/lib64/qt5/bin/lrelease)
Strip the version to avoid this, resulting in a cleaner log:
Detecting Qt5 tools
Program /usr/lib64/qt5/bin/moc found: YES 5.14.2 (/usr/lib64/qt5/bin/moc)
Program /usr/lib64/qt5/bin/uic found: YES 5.14.2 (/usr/lib64/qt5/bin/uic)
Program /usr/lib64/qt5/bin/rcc found: YES 5.14.2 (/usr/lib64/qt5/bin/rcc)
Program /usr/lib64/qt5/bin/lrelease found: YES 5.14.2 (/usr/lib64/qt5/bin/lrelease)
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* depenencies/llvm: Handle llvm-config --shared-mode failing
Fixes: #7371Fixes: #7878
* test cases/llvm: Refactor to use test.json
Instead of trying to cover everything internally
Sometimes, distros want to configure a project so that it does not
use any bundled library. In this case, meson.build might want
to do something like this, where slirp is a combo option
with values auto/system/internal:
slirp = dependency('', required: false)
if get_option('slirp') != 'internal'
slirp = dependency('slirp',
required: get_option('slirp') == 'system')
endif
if not slirp.found()
slirp = subproject('libslirp', ...) .variable('...')
endif
and we cannot use "fallback" because the "system" value should never
look for a subproject.
This worked until 0.54.x, but in 0.55.x this breaks because of the
automatic subproject search. Note that the desired effect here is
backwards compared to the policy of doing an automatic search on
"required: true"; we only want to do the search if "required" is false!
It would be possible to look for the dependency with `required: false`
and issue the error manually, but it's ugly and it may produce an error
message that looks "different" from Meson's.
Instead, with this change it is possible to achieve this effect in an
even simpler way:
slirp = dependency('slirp',
required: get_option('slirp') != 'auto',
allow_fallback: get_option('slirp') == 'system' ? false : ['slirp', 'libslirp_dep'])
The patch also adds support for "allow_fallback: true", which is
simple and enables automatic fallback to a wrap even for non-required
dependencies.
Force_fallback is not an interpreter keyword argument, and there
is no reason to handle it as one since it is not used anywhere
else (and in fact is explicitly ignored by get_dep_identifier).
Use a Python keyword argument instead, which makes the code
simpler.
with msys ncurses-config returns a unix style path (currently, though
it's been fixed upstream), which the compilers don't understand, so we
can't do that. Additionally, while the system search does work, there's
missing include directories that need to be added.
On win32 there is pdcurses, so we detect it first, because python
depends on ncursesw, so if we don't want to use ncursesw, we should make
sure pdcurses detect before ncursesw
has_header returns a tuple of (found: bool, cached: bool), so `if
has_header` will always return true because the tuple is non-empty. We
need to check if the found value is true or not.
Instead of the default ones, this is especially important when cross
compiling or when using compilers that aren't compatible with the
default ones.
squash! dependencies/hdf5: Use the actual system compilers