Since intl links internally to iconv, try to pull in iconv too, but only
if we specifically ask for static libs.
If PREFER_SHARED, we have no way to tell which type we got, so do not
try handling that...
Although find_library returns the library as a list of args, has_header
returns a tuple(is_found, is_cached) which is non-empty and thus always
true. Which is confusing...
Check whether it actually got found.
Just like we automatically provide some reusable glue for self.static,
provide it here too. It seems plausibly like something people would
commonly want.
Both of these are artifacts of the time before Dependency Factories,
when a dependency that could be discovered multiple ways did ugly stuff
like finding a specific dependency, then replacing it's own attributes
with that dependency's attributes. We don't have cases of that left in
the tree, so let's get rid of this code too
* dependencies: Deterministic LLVM compile and link arg ordering
In LLVMDependencyConfigTool, the members compile_args and required_modules are
either converted to or stored as sets, which do not have a stable ordering. This
results in nondeterministic builds, particularly with required_modules causing
the order in which the LLVM libraries are linked in to the output binaries to
change across independent builds. As any guarantee about ordering for
compile_args is lost by being converted from a list to a set and back, and the
modules added to required_modules was even already sorted once, sort both when
converting them to lists.
* Use mesonlib.OrderedSet instead of sorting the sets.
Co-authored-by: Kaelyn Takata <kaelyn.alexi@protonmail.com>
This commit introduces a new type of `HoldableObject`: The
`SecondLevelHolder`. The primary purpose of this class is
to handle cases where two (or more) `HoldableObject`s are
stored at the same time (with one default object). The
best (and currently only) example here is the `BothLibraries`
class.
Checking how to aquire the *gettext family of symbols portably is
annoyingly complex, and may come from the libc, or standalone.
builtin dependency:
This detects if libintl is unneeded, because the *gettext family of
symbols is available in the libc.
system dependency:
This detects if libintl is installed as separate software, linkable via
-lintl; unfortunately, GNU gettext does not ship pkg-config files for
it.
Fixes#3929
mesonbuild.dependencies.__init__ exposes configtool, pkgconfig, cmake
and more in __init__.py, so there's no reason we should be tying
SystemDependency to the internal organization implementation of the
subpackage!
In the 2nd previous commit it took quite some effort to figure out that
the python module "does not exist" because of import errors while
refactoring something completely different.
For dependencies that on some systems are built into libc etc. and don't
need to be separately linked. This is distinct from "system"
dependencies which add linker args.
This allow mypy to catch cases where we accidently assign the dependency
name to the type_name, as it sees them as having different types (though
at runtime they're all strings).
Currently if the version returned is not a supported version, then you
get a lovely stack trace. This is not nice. This can be triggered easily
by adding gcc's `-fdirectives-only` flag, which stops the preprocessor
from doing certain macro expansions, including those used to detect
OpenMP.
Fixes#8652
Instead of using qmake, use config-tool. This is no different than when
we deprecated the other per-dependency config-tool types (sdl2-config,
llvm-config, etc) for just config-tool
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.
Eli Schwartz
Dylan Baker
kira78
Daniel Mensinger
Jon Turney
Xavier Claessens
Tristan Partin