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/
```
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
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.
We expose detect.py as the mesonbuild.dependencies entrypoint and import
it upfront everywhere. But unless the `dependency()` function is
actually invoked, we don't need *any* of the private implementations for
this.
Avoid doing so until, as part of actual dependency lookup, we attempt
that specific dependency method. This avoids importing big modules if
`method:` is specified, and in most cases hopefully pkg-config works and
we can avoid importing the cmake implementation particularly.
Actually avoiding most of these imports requires more refactoring. But
even so, the garden path no longer needs to import the dub dependency
impl.
We need to extend the candidates the same way per method, but we handle
each method twice: once in explicit method checks, and once for auto. We
can just handle auto as a special list of methods, though.
Currently you can only use one of qt4, qt5, qt6 in a single project
when using a machine file because the config-tool lookup for qt only
looks at `qmake` in the machine files, instead of looking up the
binary names directly.
Allow specifying `qmake` `qmake4` `qmake5` and `qmake6`.
This is necessary for gstreamer, which can build separate qt5 and qt6
plugins that are distributed as static libraries, so the user can pick
which one to use.
* DubDependency._check_dub returns the version
* check for compatible Dub version
Dub versions starting at 1.32 have a new cache structure
into which Meson doesn't know where to find compatible artifacts
* skipping D tests involving Dub
* refactor _check_dub
makes mypy happier
* make linters happy
* localize some logic
CPython adds a hard to avoid hardcoded link flag to look for a debug
libpython. This results in a very puzzling error, so emit a warning
with a clear message. Note that pybind11 has a workaround for this,
which undefines `_DEBUG`. So users who use only pybind11 can use
non-release buildtypes, but they won't get debug symbols on Windows
unless they have a debug build.
If the dependency permits it, we can just do a PATH search instead of
mandating that it be listed in the cross file. This is useful for the
limited case where a specific dependency is known to be compatible with
any machine choice.
Mark the pybind11 dependency as supporting this. It's a valid choice
because pybind11 is a header-only C++ library.
On Windows, the SDL2 library is generally provided with only CMake config
files. This commit allows meson to fallback on CMake as a last resort to
find the SDL2 library.
import('python').find_installation('python').version() causes exception
because of a missing initialization, when `find_installation()` receives
a name or a path.
This will help with the writing of tools to generate
VisualStudio project and solution files, and possibly
for other IDEs as well.
- Used compilers a about `host`, `build` and `target` machines
arere listed in `intro-compilers.json`
- Informations lister in `intro-machines.json`
- `intro-dependencies.json` now includes internal dependencies,
and relations between dependencies.
- `intro-targets.json` now includes dependencies, `vs_module_defs`,
`win_subsystem`, and linker parameters.
pyconfig.h defines it in limited cases, but as empty, rather than as "1"
which is what command-line defines generally do. Explicitly define it as
a compatible definition so the compiler does not log a warning that the
value has changed.
Fixes#11592
Eli Schwartz
Xiang Gao
Christoph Reiter
Alan Coopersmith
Xavier Claessens
Charles Brunet
Nirbheek Chauhan
David Seifert
Eli Schwartz
Andrew McNulty
Dylan Baker
Lucas Alber
George Sedov
Karol Herbst
Matthew Waters
Remi Thebault
Volker Weißmann
Radek Bartoň
Ralf Gommers
Matthieu Bouron
Josh Soref
Helen Ginn