On python >=3.8, this information is expected to be encoded in the
sysconfig vars.
In distutils, it is always necessary to link to libpython on Windows;
for posix platforms, it depends on the value of LIBPYTHON (which is the
library to link to, possibly the empty string) as generated by
configure.ac and embedded into python.pc and python-config.sh, and then
coded a second time in the distutils python sources.
There are a couple of caveats which have ramifications for Cygwin and
Android:
- python.pc and python-config.sh disagree with distutils when python is
not built shared. In that case, the former act the same as a shared
build, while the latter *never* links to libpython
- python.pc disagrees with python-config.sh and distutils when python is
built shared. The former never links to libpython, while the latter do
The disagreement is resolved in favor of distutils' behavior in all
cases, and python.pc is correct for our purposes on python 3.12; see:
https://github.com/python/cpython/pull/100356https://github.com/python/cpython/pull/100967
Although it was not backported to older releases, Cygwin at least has
always patched in a fix for python.pc, which behavior is now declared
canonical. We can reliably assume it is always correct.
This is the other half of the fix for #7702
Since 3.10.3, Debian finally started patching sysconfig with custom
paths, instead of just distutils. This means we can now go use that
instead. It reduces our reliance on the deprecated distutils module.
Partial fix for #7702
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.
ExternalProgram currently assumes that if a command is passed it exists
and can be used as is. In case we extract the path from pkgconfig the
path might not exist, on Windows it might be missing the ".exe" suffix.
By passing the variables as a name ExternalProgram will validate that
the command exists at configure time and will fail if not, and it will
try to fixup the command by appending .exe etc.
Fixes#12271
This differentiates export_dynamic being explicitly set to False from it
being unset. This allows us to deprecate explicitly setting
export_dynamic to false, but setting implib. This is already the case in
the other direction, if implib is False but export_dynamic is enabled
then we get a hard error.
This also moves the validation up to the Interpreter and out of the
build level.
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
In commit dd22546bdd the various
typed_pos_args for different BuildTarget functions was refactored into a
common tuple of types.
It overlooked the fact that jar specifically does NOT accept the same
types, and began to allow passing structured_sources in.
The former is unix-only, which complains when running on the Windows
platform -- even though this code is in a unix-specific branch.
But per the docs:
> As of Python 3.3, this is equivalent to os.chmod(fd, mode).
So we can just use the identical function that is available in more
places.
It should *be* a version comparison. We are guaranteed to get a
two-element version number, which also parses as a float but a float
doesn't correctly handle version sorting when the second component
differs in number of digits.
The standard way to handle this is by comparing tuples such that each
component is an integer. Do so here.
Fixes#12195
Co-authored-by: George Koehler <xkernigh@netscape.net>
(for unittests)
The logic previously added to distinguish between illumos and Solaris made use of a uname invocation with a -o switch which is not supported on Solaris 5.10 or earlier.
illumos started with version 5.11 so the logic has been shortcut to report 'solaris' in such cases where the version is 5.10 or below.
This means that arguments set via `add_global_arguments`,
`add_project_arguments` and by either the `-Dc_args` or `CFLAGS` are
applied to bindgen as well. This can be important when, among other
things, #defines are set via these mechanisms.
Fixes: #12065
Needed a classpath set in the current working directory.
This was on a Zulu build of OpenJDK 11.0.17 on a macOS ARM machine.
The errors folks might encounter:
Error: Could not find or load main class SanityCheck
Caused by: java.lang.ClassNotFoundException: SanityCheck
Add the `clang-tidy-fix` target to apply clang-tidy fixes to the source
code.
This is done by calling `run-clang-tidy` with `-fix` argument.
Add a test case to run `clang-tidy-fix` and verify the file is changed.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
c++26 support was added in #11986, but regressed in #10332 because
the versions now get checked against the global _ALL_STDS list, and
c++26 was missing there.
Fix by adding c++26 to _ALL_STDS
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.
The method can be overridden by setting the `method` key in the wrap
file and always defaults to 'meson'. cmake.subproject() is still needed
in case specific cmake options need to be passed.
This also makes it easier to extend to other methods in the future e.g.
cargo.
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
Rustc expects to be provided both a search path `-L`, and a link arg `-l
kind=libname`, but we don't handle that correctly. Because we combine -L
and -l arguments from pkg-config the backend must rematerialize the -L
and -l split. We currently don't do this for static archives.
Pulled from this list on Xcode 15 beta:
$ clang -E -dM -xobjective-c++ -std=arglbargle -o - /dev/null
error: invalid value 'arglbargle' in '-std=arglbargle'
note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard
note: use 'c++11' for 'ISO C++ 2011 with amendments' standard
note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard
note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard
note: use 'c++17' for 'ISO C++ 2017 with amendments' standard
note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard
note: use 'c++20' for 'ISO C++ 2020 DIS' standard
note: use 'gnu++20' for 'ISO C++ 2020 DIS with GNU extensions' standard
note: use 'c++2b' for 'Working draft for ISO C++ 2023 DIS' standard
note: use 'gnu++2b' for 'Working draft for ISO C++ 2023 DIS with GNU extensions' standard
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Rustc does not produce object files we can reuse to build both
libraries. Ideally this should be done with a single target that has
both `--crate-type` arguments instead of having 2 different build rules.
As temporary workaround, build twice and ensure they don't get conflicts
in intermediary files created by rustc by passing target's private
directory as --out-dir.
See https://github.com/rust-lang/rust/issues/111083.
Tristan Partin
Dylan Baker
Marvin Scholz
Charles Brunet
Eli Schwartz
Eli Schwartz
Christoph Reiter
Xiang Gao
Luke Elliott
CorrodedCoder
Alan Brooks
Lei YU
Xavier Claessens
Kunwu.Chan
Alan Coopersmith
Steven Noonan