- check version of DUB for compatibility with Meson
- use "cacheArtifactPath" to locate DUB libraries in the cache
- propose `dub build --deep` command to Meson users for missing DUB
packages
Depending on DUB version, it will look either in the old cache structure
or use this new `dub describe` entry.
It's always true because the func is always a real, truthy func object.
In the cmake case, the logic seems to be broken because if a path is not
a file, then that includes the case where it does not exist. It also
clearly meant "or" instead of "and".
What actually ended up happening was that this check never fired at all.
Because "if not func and not ..." would always fail, because "not func"
is always false. Maybe we don't need this logic at all...
The existing "*-linux-gnu*" works on the Debian multiarch model for
Linux architectures; tweak it to be "*-gnu*" so it works also for Hurd
architectures.
This makes the cmake-based search of dependencies work on Debian
GNU/Hurd.
Revert "interpreter: when overriding a dependency make its name match"
This reverts commit b1340e9bb1.
Revert "dependency: define equality and hash operators for Dependency"
This reverts commit 6d713e40f8.
This caused some projects to fail to build, such as libplacebo and
libepoxy. Taking libplacebo as the example, the produced build.ninja
does not include libvulkan.so as a linker input for
src/libplacebo.so.338.
We are probably getting dependency hashing wrong somewhere. Unsure where
exactly and unsure how to create a test case. We are also deep into rc2.
Revert it for now and try to re-land these changes for 1.6.
Bug: https://bugs.gentoo.org/935443Fixes: #13352
When building a limited API module on Windows the library
to link with should be python3.dll, not python3X.dll. This was
already the case for non-GCC, but should have been the case
unconditionally.
It was probably done this way originally since we didn't have the
`fatal` keyword argument to avoid triggering the fatal-meson-warnings.
While we're here, replace the use of a `if bool` with an `else` on the
for loop.
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
This does a couple of things:
1. Scrape the `Py_GIL_DISABLED` sysconfig var, which is the best way as of today
to determine whether the target interpreter was built with `--disable-gil`
2. link against the correct libpython
3. On Windows, work around a known issue in the python.org installer with a
missing define in `pyconfig.h`, which the CPython devs have said is unlikely
to be fixed since headers are shared between the regular and free-threaded
builds in a single NSIS installer.
`boost_root` doesn't work if lib and include are in different directories like in the `nix` `boost` package.
The `prefix` checking could probably be removed, in 2019 conan (the
reason why the check was added) had `libdir` and `includedir` in its
generated pkg-config file
https://www.github.com/mesonbuild/meson/issues/5438#issuecomment-498761454
If there's no return then boost isn't found for some reason, further
logic is unnecessary in any case if direct paths are passed.
`roots += [Path(boost_lib_dir), Path(boost_inc_dir)]` did not work
This is in preparation for a future commit which makes it
possible for a PythonPkgConfigDependency to be used in a
context where previously only a PythonSystemDependency would
be used.
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
more subtle failures, such as CUDA modules not being found
anymore.
* We need to simplify these CUDA modules when nvcc is used for
linking, since this may have side-effects from the cuda toolchain.
Closes: #13240
* In `CudaDependency._detect_language`, the first detected language is
considered the linking one. Since `nvcc`/`cuda` implicitly know where the
cuda dependency lives, this leads to situations where `cpp` as linking
language is erroneously detected as `cuda` and then misses the `-L` argument.
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.
We have seen a number of bugs from people confused by warning that the
need both a C and C++ compiler to use the CMake method. This attempts
to provide a more helpful error message.
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
It's an improper object model, but was used to signal to a subclass that
self.traceparser did not exist. However, since it is always initialized
from self.cmakebin, we can just check that instead.
In 89146e84c9, a heuristic was introduced where
if libLLVMSupport is available as a static library, LLVM itself is assumed
to be availble as a static library as a whole.
This is unfortunately not the case at least on Gentoo and Arch Linux, where
a subsequent llvm-config call yields:
```
$ /usr/lib/llvm/17/bin/llvm-config --libfiles --link-static
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMTargetParser.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBinaryFormat.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBitstreamReader.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMRemarks.a
[...]
```
On Gentoo, where LLVM's static libraries are not included, we still have:
```
$ equery f llvm:17 | grep -i lib64/.*.a$
/usr/lib/llvm/17/lib64/libLLVMDemangle.a
/usr/lib/llvm/17/lib64/libLLVMSupport.a
/usr/lib/llvm/17/lib64/libLLVMTableGen.a
/usr/lib/llvm/17/lib64/libLLVMTestingAnnotations.a
/usr/lib/llvm/17/lib64/libLLVMTestingSupport.a
/usr/lib/llvm/17/lib64/libllvm_gtest.a
/usr/lib/llvm/17/lib64/libllvm_gtest_main.a
```
Therefore, testing for libLLVMSupport is insufficient. We now try libLLVMCore
instead, as that appears to only be installed when LLVM truly has static libraries
available. libLLVMCore is handled as a LLVM component which gives us some guarantee
this is supposed to be happening and not a fluke.
(Specifically, LLVM's llvm/lib/Support/CMakeLists.txt pays 0 attention to
-DLLVM_BUILD_LLVM_DYLIB and -DLLVM_LINK_LLVM_DYLIB, and is hence only affected
by -DBUILD_SHARED_LIBS, which LLVM upstream say is only to be used for development.
Therefore, with -DBUILD_SHARED_LIBS=OFF (as is recommended/the default) and
-DLLVM_BUILD_LLVM_DYLIB=ON, you will get a static libLLVMSupport, without it
indicating anything about the rest of your configuration.)
Closes: https://github.com/mesonbuild/meson/issues/12323
Fixes: 89146e84c9
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
CMake really prefers ON/OFF and in some cases, depending on how the condition
is written, ON/OFF vs other "truthy" (as far as CMake's lang supports) values
work differently. Just be safe and use ON/OFF.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
When hdf5 is built with cmake instead of autotools, it makes a number of
weird changes. What we care about in particular is that h5cc exists but
doesn't work -- it happily ignores -show and tries to compile stuff,
then leaves us with a dependency that has no libraries, and fails when
running `ninja`.
See: #12748
This should have been done in my earlier fix, but kinda forgot to test and
fix it there as well.
See https://github.com/mesonbuild/meson/pull/11733 for the discussion.
Fixes: 8284be813 ("dependencies/llvm: strip default include dirs")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
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
The code assumed that sysconfig.get_platform() returns "mingw" for mingw Python,
but that's no longer the case for 2.5 years now, as it now only starts with
"mingw" and contains further information like the arch and other ABI relevant things
to avoid conflicts.
This updates the detection code to the current status quo. mingw Python only documents
right now that it starts with "mingw", and none of that arch stuff, but it's
unlikely that this will change, and this looks less error prone than looking at CC.
Fixes#12547
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
We do not use setuptools for anything, and only lightly use distutils.
Unpredictable issues can occur due to setuptools monkey-patching, which
interferes with our intended use. Tell setuptools to simply never get
involved.
Note: while it's otherwise possible to check if the probe is run using
sys.executable and avoid forking, setuptools unconditionally injects
itself at startup in a way that requires subprocess isolation to
disable.
Remi Thebault
Eli Schwartz
Pino Toscano
Jussi Pakkanen
Randy Eckenrode
Andres Freund
Andrew McNulty
Dylan Baker
Dudemanguy
Ralf Gommers
Artturin
David Seifert
kkz
Jonathan Schleifer
Jonathon Anderson
Otto Moerbeek
L. E. Segovia
Sam James
Peter Urban
Karol Herbst
Christoph Reiter
Tristan Partin
Charles Brunet