| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Static must be optional, because although the default is static=false,
we special case that static : false is different than static being not
set in a number of cases.
|
|
Almost exactly the same as how the dl dependency works. On certain
systems (like BSDs that use clang), stdatomic is provided by compiler-rt
and doesn't need a separate library explictly linked. On a typical
GNU/LINUX system, atomic is a separate library that must be explictly
found and linked against. So just add a builtin and system method for
these two use cases.
|
|
|
|
This uses objfw-config to get to the flags, however, there's still
several todos that can only be addressed once dependencies can have
per-language flags.
|
|
These are being added for NumPy 2.0 The implementation closely follows
the one for the pybind11 dependency.
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
Simply store the module it is expected to be found in. That module then
appends to the packages dict, which guarantees mypy can verify that
it's got the right type -- there is no casting needed.
|
|
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
|
|
Do not import it and expose it at the package scope, it's never used
elsewhere except inside the dub module.
|
|
This works with pkg-config and cmake without any special support. The
custom factory adds further support for config-tool, via
`pybind11-config`. This is useful because the config-tool will work out
of the box when pybind11 is installed, but the pkg-config and cmake
files are shoved into python's site-packages, which is an unfortunate
distribution model and makes it impossible to use in an out of the box
manner.
It's possible to manually set up the PKG_CONFIG_PATH to detect it
anyway, but in case that does not happen, having the config-tool
fallback is extremely useful.
|
|
We have two copies of this code, and the python module one is vastly
superior, not just because it allows choosing which python executable to
base itself on. Unify this. Fixes various issues including non-Windows
support for sysconfig, and pypy edge cases.
|
|
|
|
Add a MissingCompiler class returned by compiler detecting methods
intead of None - accessing such an object raises a DependencyException
Fixes #10586
Co-authored-by: duckflyer <duckflyer@gmail.com>
|
|
By default, meson will try to look for shared libraries first before
static ones. In the meson.build itself, one can use the static keyword
to control if a static library will be tried first but there's no simple
way for an end user performing a build to switch back and forth at will.
Let's cover this usecase by adding an option that allows a user to
specify if they want dependency lookups to try static or shared
libraries first. The writer of the meson.build can manually specify the
static keyword where appropriate which will override the value of this
option.
|
|
Extract to a separate function the code that resolves dependencies
for compiler methods. We will reuse it for add_project_dependencies().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
|
|
On some platforms, this is provided by the base system, which
nevertheless refrains from providing the .pc files that go along with
it. As a result, it's impossible to sensibly find these dependencies.
I'm looking at you, FreeBSD...
Upstream tracking bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659
This is also a problem on macOS, but that's unfixable (and I believe
they provide some truly ancient and out-of-support version anyway) and
you probably want to use the homebrew OpenSSL. Still, meson can now
detect these old versions and even set their version number.
|
|
|
|
Also internally needed by intl, so add that as a proxied dependency
instead of coding it manually.
|
|
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.
|
|
|
|
Split the Factory and dependency classes out
of the base.py script to improve maintainability.
|
|
The JDK system dependency is important for detecting JDK include paths
that may be useful when developing a JNI interface.
|
|
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 big enough and complicated enough bit of code that it deserves
its own module.
|
|
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.
|
|
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.
|
|
|
|
Instead of a mega dependency that does everything, use a dependency
factory for config-tool and pkg-config
|
|
This makes use of proper ConfigTool and PkgConfig dependencies rather
than one big ExternalDependency that internally creates other
dependencies and then copies their attributes.
|
|
Basically this breaks down into three cases. An open source version with
compliant PkgConfig, valid CMake, and a Intel implementation that has
completely broken PkgConfig. For the first two cases we can use standard
classes, for the last we can make a subclass of PkgConfigDependency that
handles the special logic.
This doesn't change any of the logic, but it does re-organize it to be
clearer, and make use of the dependency factory API, which makes other
things (like Dependency.get_variable) work.
This is untested with Intel MKL.
|
|
This comes pre-installed, but currently we don't have a way to detect it
without relying on pkg-config or cmake. This is only valid with the
apple clang-based compilers, as they do some special magic to get
headers.
|
|
|
|
|
|
|
|
This lets us make a number of uses of threads safer, because we can use
the threads_factory instead of the ThreadDependency
|
|
This uses a custom factory because that makes more sense here, since we
need logic to decide what pkg-config files to look for
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
