The MSVC linker errors out if a line in the rspfile is too long.
The resolution is to use the built-in ninja keyword $in_newline instead of $in, which splits each input into separate lines.
A rebase of the current branch is the wrong thing to do if the
revision (branch) specified in the wrap changed, which is the case in
the majority of cases, such as when switching from one release branch
to another.
Don't leave the subproject tree in a broken / conflicting state. The
user is most likely not a git expert who will know what magic command
to run to fix their source tree.
GCC 12.3 and Clang 16 support -std flags for c++23/c++2b.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Backported-by: Nirbheek Chauhan <nirbheek.chauhan@gmail.com>
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Backported-by: Nirbheek Chauhan <nirbheek.chauhan@gmail.com>
The c++23 mappings apply to current production compilers (GCC, Clang).
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Backported-by: Nirbheek Chauhan <nirbheek.chauhan@gmail.com>
This most likely happens when the source archive has files which take
advantage of case sensitivity, and someone is unfortunate enough to have
to work with broken operating systems that do not have the capacity to
use modern technology, like the 1970s invention of case sensitive
filesystems.
For example, Windows and macOS both have retrocomputing environments,
where case sensitive abilities were carefully removed from modern
filesystems in order to share the delights of classical computing with
the masses.
On such systems, innocent tarballs fail to extract with:
```
OSError: [Errno 22] Invalid argument: 'C:\path\to\file'
```
thereby demonstrating Microsoft's unbounded and enthusiastic love for
users (who are, universally, retrocomputing fans).
n.b. there is, begrudgingly, a secret option for crazy people who hate
retrocomputing to enable modern 1970s computing on Windows systems.
Naturally, no one with any sense would ever use this, and it is rightly
left in its sensible default in for example Github Actions.
Fixes#12344
lcov 2.0 deprecates `--rc lcov_branch_coverage=1` for `--rc branch_coverage=1` and
gives an error when an exclude is used on a non existing directory.
I added a version check for lcov and removed the subprojects directory from the
exclusion list if it does not exist.
Fixes#11995
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 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
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
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.
Since CPython 3.8 .pyd files no longer look in PATH for loading libraries,
but require the DLL directory to be explicitely added via os.add_dll_directory().
This resulted in those tests failing with 3.8+ on Windows.
Add the DLL build directory with os.add_dll_directory() to fix them.
This was never noticed in CI because it only uses Python 3.7 and the
MSYS2 CPython still used the old behaviour until now.
meson tests enable PYTHONWARNDEFAULTENCODING by default and
make EncodingWarning fatal too.
Starting with Python 3.11 CPython not only warns if no encoding is passed
to open() but also to things like subprocess.check_output(). This made
the call in vsenv.py fail and in turn made test_vsenv_option fail.
check_output() here calls a .bat file which in turn calls vcvars. I don't
know what the encoding is supposed to be used there, so just be explicit
with the locale encoding to silence the warning.
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
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
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.
The interpreter takes significant amount of time to initialize
everything in project() function. We only need to extract a string from
AST, just like we do in handle_meson_version_from_ast().
Nirbheek Chauhan
Xavier Claessens
Ada
Benjamin Redelings
Steven Noonan
Eli Schwartz
Nigel Kukard
Charles Brunet
Eli Schwartz
Alan Coopersmith
Jussi Pakkanen
Christoph Reiter
Xiang Gao
Albert Tang
Kunwu.Chan
CorrodedCoder
Dylan Baker
Alan Brooks