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
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 finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
This catches some optimization problems, mostly in the use of `all()`
and `any()`. Basically writing `any([x == 5 for x in f])` vs `any(x == 5
for x in f)` reduces the performance because the entire concrete list
must first be created, then iterated over, while in the second f is
iterated and checked element by element.
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
CMakes `target_link_libraries()` supports certain keywords to
only enable specific libraries for specific CMake configurations.
We now try our best to replicate this for Meson dependencies.
Fixes#9197
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 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).
Xiang Gao
Xavier Claessens
Charles Brunet
Eli Schwartz
Volker Weißmann
Josh Soref
Dylan Baker
Alf Henrik Sauge
Daniel Mensinger
Jon Turney