This should be an error, not an assert as it asserts nothing,
in fact, if this wouldn't error out because of the wrong type
passed to the assert, it would even do the wrong thing.
Follow-up to #12223
Regression in commit 0af126fec7. We added
support for some "test cases/" stuff that actually relies on test files
being a symlink, but when testing the image builder, we copied the meson
repository contents into the docker container without telling python
that it is in fact super important to copy symlinks as symlinks.
As a result, the tests themselves ran fine when merging, but caused the
image builder to thereafter fail.
They do not appear to have 20 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 21.
Last time we chose one randomly and hoped it doesn't keep changing
value. This dismally failed: 20 was upgraded to 21. It looks like 17 may
have some staying power.
Testing the correctness of the `modules: ` kwarg can be done with other
guaranteed stdlib modules that are even more guaranteed since they
didn't get deprecated for removal.
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 unittest case for `clang-tidy-fix` checks if the whole project is in
git or not, and skips if not.
Fix this by creating a temporary git repo, copy the test files and run
the tests, following how `clang-format` does.
It also reverts some help code introduced in the previous test.
Tested: Verify the test case passes.
Signed-off-by: Lei YU <yulei.sh@bytedance.com>
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)
Xcode always fails here because this makes the PCH not be the first
included header, causing Xcode to ignore it completely. There is no
way around this.
This has never, ever, ever worked. You can get away with it a tiny, tiny
bit, iff you magically assume several things about both internal
implementations, as well as the project source layout and builddir
location.
This can be witnessed by the way using files() was mercilessly tortured
through joining the undefined stringified format value of the file to
the current source dir... because it didn't actually *work*, the
stringified value isn't an absolute path or a builddir-relative one, but
it works as long as you do it from the root meson.build file.
Furthermore, this triggers a deprecation warning if you do it. And using
it for files() is frivolous, the "static map file" case was correct all
along.
Fix the configure_file case to demonstrate the same painful hoops we
must jump through to get custom_target outputs to work correctly.
Fixes#12259
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.
Tristan Partin
Dylan Baker
Marvin Scholz
Eli Schwartz
Charles Brunet
Eli Schwartz
Alan Coopersmith
Jussi Pakkanen
Christoph Reiter
Michael Gene Brockus (Dreamer)
Xiang Gao
Lei YU
Albert Tang
Luke Elliott
CorrodedCoder
Alan Brooks