It would be too difficult and probably a layering violation to give an
interpreter handle to the inner guts of every dependency. What we can do
instead is let every dependency track:
- the Feature checks it can produce,
- the version attribute for when it was implemented
while leaving the interpreter in charge of actually emitting them.
We currently cannot make this work because inside dependency() we don't
know the current subproject. We would also like the optional but
extremely useful location node, but we don't have that either...
Convert the broken code to a FIXME for visibility.
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
All changes were created by running
"pyupgrade --py3-only"
and committing the results. Although this has been performed in the
past, newer versions of pyupgrade can automatically catch more
opportunities, notably list comprehensions can use generators instead,
in the following cases:
- unpacking into function arguments as function(*generator)
- unpacking into assignments of the form x, y = generator
- as the argument to some builtin functions such as min/max/sorted
Also catch a few creeping cases of new code added using older styles.
Dependencies are currently printed as
[<mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeac70>, ' ', <mesonbuild.mlog.AnsiDecorator object at 0x7faa85aeab50>]
This was introduced in commit adb1b2f3f6, due to
an incorrect type annotation on the AnsiText constructor. Fix both the
annotation and the usage.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
GTestDependencySystem (and other similar dep classes) sets
self.is_found=True, but the version check could still fail. In the case
the dependency is not required `ExternalDependency._check_version()`
won't raise an exception and thus the dependency is accepted.
_check_version() sets self.is_found() in the case self.version is not
empty, we should do it too when self.version is empty.
Fixes: #9036.
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
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.
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).
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.
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
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 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.