PyTorch officially only supports setuptools. They are trying to move away from it. You may be interested in their analysis of meson and scikit-build-core atpytorch/pytorch#157807.

That is for building PyTorch itself, which is quite different from "build an extension module against the PyTorch C++ API". For the latter, multiple build systems are supported and any build system that sets up the right compile and link flags should work. The question is just how easy it is, which varies:

• Forsetuptools, there ishttps://docs.pytorch.org/docs/stable/cpp_extension.html
• For CMake, PyTorch itself shipsTorchConfig.cmake andTorchConfigVersion.cmake (generated at build time and shipped inside the source tree intorch/share/cmake/Torch), so you can usefind_package(Torch REQUIRED). There are notes on this inhttps://docs.pytorch.org/tutorials/advanced/cpp_frontend.html; you have to setCMAKE_PREFIX_PATH and make sure it's an absolute path.
  • The Python module installs cmake files and headers under the Python's site-packages directory that can't be used pytorch/pytorch#116478 is relevant for that.
• There is nopkg-config support unfortunately (xrefProvide a pkg-config file pytorch/pytorch#56465)
• Other build systems are more DIY, likethis for Bazel anddaknuett/extension-cpp-meson for Meson.

I think there's not much Meson usage because of the lack of solid CUDA support; CMake is pretty much the standard there. For CPU it shouldn't be too difficult. I like the approach thatdaknuett/extension-cpp-meson is taking to extract paths/flags fromtorch.utils.cpp_extension dynamically, that should be more maintainable than hardcoding paths.

I'll try to find time to test and see what the problem is. Also Cc@daknuett for visibility (I hope you don't mind the ping).

I agree with you that the approach of daknuett is a better approach. I hard-coded just to see if it would work without the --no-build-extension flag. Using the meson.build as is from daknuett and with the --no-build-extension flag also produces the same undefined symbol error. I am also trying to figure out why this is happening.

I am wondering what kind of support meson provides for CUDA currently?

https://mesonbuild.com/Cuda-module.html
https://mesonbuild.com/Dependencies.html#cuda
executable('myprog', 'myprog.cu')

I'm not a CUDA user but I know we have a bunch of happy users of our CUDA support.

Torch (and specifically its C++ ABI) is not CUDA -- it's possible to have integrated support for the latter and not the former, clearly.

CUDA support in Meson seems to be missing compute capability 8.9, 9, 10, 12 in the docs; implementation looks partial (itdoes have 8.9 and 9.0, but nothing beyond that). CUDA 13 was also just released and needs to be addedhere.

I had wanted to poke at this PyTorch support a bit (since I do work on and with PyTorch), but I am unlikely to get around to it soon unfortunately.

I am wondering if one of you (@rgommers@eli-schwartz ) could point me to how do I create a ninja rule like the following using meson:

rule compile  command = $cxx -MMD -MF $out.d $cflags -c $in -o $out $post_cflags  depfile = $out.d  deps = gcc

@daknuett, I am wondering what is your setup? After cloning extension-cpp-meson, I created a virtual environment inside the extension-cpp-meson directory, installed torch, numpy, meson-python, ninja. After that I tried the following command as per your README.

python -m pip install --no-build-isolation .

I get the following error.

  ../meson.build:27:17: ERROR: Tried to form an absolute path to a dir in the source tree.  You should not do that but use relative paths instead, for  directories that are part of your project.

I am wondering how did you not encounter that?

It should suffice to add the post_cflags via meson's support forcpp_args on a specific target, or viaadd_project_arguments().

Thank you for your response@daknuett. I still face the unresolved symbol issue. However, I think I found the reason for the undefined symbol.

First, in site_packages/extension_cpp, I used nm to find:

site-packages/extension_cpp$ nm -u --demangle _C.cpython-313-x86_64-linux-gnu.so | grep DispatchKey | grep -v Guard                 U torch::Library::Library(torch::Library::Kind, std::string, std::optional<c10::DispatchKey>, char const*, unsigned int)

Then, in site_packages/torch/lib, I used nm to find:

site-packages/torch/lib$ nm -a --demangle * | grep 'torch::Library::Library'nm: libgomp.so.1: no symbols00000000018eebd0 T torch::Library::Library(torch::Library::Kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<c10::DispatchKey>, char const*, unsigned int)00000000018eebd0 T torch::Library::Library(torch::Library::Kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<c10::DispatchKey>, char const*, unsigned int)0000000000ec5c72 t torch::Library::Library(torch::Library::Kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<c10::DispatchKey>, char const*, unsigned int) [clone .cold]                 U torch::Library::Library(torch::Library::Kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<c10::DispatchKey>, char const*, unsigned int)                 U torch::Library::Library(torch::Library::Kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<c10::DispatchKey>, char const*, unsigned int)

This appears to be related to incompatible ABIs (pytorch/pytorch#13541).

In meson.build, you have:

cxx11abi = run_command(python, ['-c', 'import torch; print(torch._C._GLIBCXX_USE_CXX11_ABI)']).stdout().strip()add_global_arguments('-D_GLIBCXX_USE_CXX11_ABI=@0@'.format(cxx11abi), language: 'cpp')

I am not sure why I still have the unresolved symbol issue.

I can confirm that I get the same error as you. I am working on it.

min_supported_cpython = run_command(python, ['-c', 'import torch.utils.cpp_extension; print(torch.utils.cpp_extension.min_supported_cpython)'], check: true).stdout().strip()
add_global_arguments('-D_Py_LIMITED_API=@0@'.format(min_supported_cpython), language: 'cpp')

I cannot confirm that. Instead I found that

diff --git a/meson.build b/meson.buildindex 5b612e7..1f26452 100644--- a/meson.build+++ b/meson.build@@ -63,8 +63,9 @@ endforeach # Defines that are required for torch compatibility                              #  # ABI compatibility-cxx11abi = run_command(python, ['-c', 'import torch; print(torch._C._GLIBCXX_USE_CXX11_ABI)']).stdout().strip()-add_global_arguments('-D_GLIBCXX_USE_CXX11_ABI=@0@'.format(cxx11abi), language: 'cpp')+cxx11abi = run_command(python, ['-c', 'import torch; print(torch._C._GLIBCXX_USE_CXX11_ABI)'], check: true).stdout().strip()+cxx11abi = cxx11abi.to_lower().contains('true') ? 1 : 0+add_project_arguments('-D_GLIBCXX_USE_CXX11_ABI=@0@'.format(cxx11abi), language: 'cpp')

Resolves the ABI issues.

Do you have a repository where I can look at this? Of course Cuda support is very much appreciated.

I do and I did submit a PR to you.

https://github.com/bumi001/extension-cpp-meson-cuda