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
This catches some very real errors.
The one in scalapack is pretty silly actually, it's failing to figure
out that the exploded list is at least two arguments. However, the code
is actually clearer by not using a list and exploding it, so I've done
that and pylint is happy too.
There was both a straight up bug in the type signature (the return type
is List[Callable[[], Dependency]] not List[Type[Dependency]]), and in
the way the arguments are assembled. Typing is pretty limited in it's
ability to express decorators, so the best mypy can do is check the
return types (I think). I've done what the docs suggest and it's stopped
complaining.
- Exceptions raised during subproject setup were ignored.
- Allow c_stdlib in native file, was already half supported.
- Eliminate usage of subproject variable name by overriding
'<lang>_stdlib' dependency name.
The compilers_detect function is only used in the qt module, which
checks every time before using a specific compiler, if it is found.
e.g.
meson.build:10:6: ERROR: MOC sources specified and couldn't find moc-qt5, please check your qt5 installation
In fact, the current check means we never even hit this error to begin
with, because we previously died on the uninformative error:
meson.build:10:6: ERROR: Program(s) ['moc'] not found or not executable
which doesn't actually tell the user why this matters, and is all around
a waste of time.
Fixes#5582
Paolo Bonzini
Antonin Décimo
Dylan Baker
Daniel Mensinger
Jason Ekstrand
Haelwenn (lanodan) Monnier
Laurent Pinchart
Yonggang Luo
Xavier Claessens
Nirbheek Chauhan
William F Godoy
Eli Schwartz