* 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.
This is to allow passing the path share/cmake/ as cmake_prefix_path.
This is a case supported by cmake and is relied on by PyTorch.
The cmake prefix of PyTorch can be found by running:
python -c 'import torch.utils; print(torch.utils.cmake_prefix_path)'
you will see something like below from the above command:
/home/gaoxiang/.virtualenvs/nvfuser/lib/python3.11/site-packages/torch/share/cmake
Inspecting this directory:
❯ tree /home/gaoxiang/.virtualenvs/nvfuser/lib/python3.11/site-packages/torch/share/cmake
/home/gaoxiang/.virtualenvs/nvfuser/lib/python3.11/site-packages/torch/share/cmake
├── ATen
│ └── ATenConfig.cmake
├── Caffe2
│ ├── Caffe2Config.cmake
│ ├── Caffe2Targets.cmake
│ ├── Caffe2Targets-release.cmake
│ ├── FindCUDAToolkit.cmake
│ ├── FindCUSPARSELT.cmake
│ ├── Modules_CUDA_fix
│ │ ├── FindCUDA.cmake
│ │ ├── FindCUDNN.cmake
│ │ └── upstream
│ │ ├── CMakeInitializeConfigs.cmake
│ │ ├── FindCUDA
│ │ │ ├── make2cmake.cmake
│ │ │ ├── parse_cubin.cmake
│ │ │ ├── run_nvcc.cmake
│ │ │ └── select_compute_arch.cmake
│ │ ├── FindCUDA.cmake
│ │ ├── FindPackageHandleStandardArgs.cmake
│ │ └── FindPackageMessage.cmake
│ └── public
│ ├── cuda.cmake
│ ├── gflags.cmake
│ ├── glog.cmake
│ ├── LoadHIP.cmake
│ ├── mkl.cmake
│ ├── mkldnn.cmake
│ ├── protobuf.cmake
│ └── utils.cmake
├── Tensorpipe
│ ├── TensorpipeTargets.cmake
│ └── TensorpipeTargets-release.cmake
└── Torch
├── TorchConfig.cmake
└── TorchConfigVersion.cmake
9 directories, 28 files
However, meson currently filters this directory out by `_preliminary_find_check`. As a result, doing
torch_dep = dependency('Torch')
will fail, even if you set `cmake_prefix_path` with the value returned by PyTorch.
Possibly related issues:
https://stackoverflow.com/questions/68884434/libtorch-c-meson-dependencyhttps://github.com/mesonbuild/meson/issues/9740https://discuss.pytorch.org/t/libtorch-meson-build/139648
llvm v17 defaults to 5.1 and without this meson fails to find
openmp: 'ERROR: Dependency "openmp" not found, tried system'
Add 5.2 as well while at it.
Makes it stop reporting that it found a static zlib on Solaris
which does not ship a static library file for libz, and thus allows
"test cases/rust/13 external c dependencies" to pass.
Fixes#10906
While at it, make more methods private by storing the version found on
the instance. That avoids having to call check_pkgconfig() as static
method from unittests.
This also makes it more consistent with get_pkgconfig_variable() which
always return empty value instead of failing when the variable does not
exist. Linking that to self.required makes no sense and was never
documented any way.
You cannot listdir() a directory that doesn't exist. This header
directory may not exist if suitable devel packages in distros with
split devel packages, aren't installed.
In theory we could raise a suitable error here. But it would be
inconsistent -- we don't otherwise validate that the Qt include
directories exist, usually just assuming they do because the dependency
was found. And this is niche code inside a non-default special kwarg.
At least for pkg-config, it's probably a bug in the distro if pkg-config
files exist but the headers don't. The qmake status is less clear.
Avoiding a crash means that at the very least, if those headers are in
fact directly used by the project, an obvious compiler error occurs
instead of a noisy meson traceback.
Fixes#12214
This commit adds a new keyword arg to extension_module() that enables
a user to target the Python Limited API, declaring the version of the
limited API that they wish to target.
Two new unittests have been added to test this functionality.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
David Seifert
Eli Schwartz
kkz
Jonathan Schleifer
Dylan Baker
Jonathon Anderson
Otto Moerbeek
L. E. Segovia
Sam James
Ralf Gommers
Peter Urban
Karol Herbst
Christoph Reiter
Tristan Partin
Charles Brunet
Xiang Gao
Alan Coopersmith
Xavier Claessens
Nirbheek Chauhan
Eli Schwartz
Andrew McNulty