_get_gnu_compiler_defines and _get_clang_compiler_defines were broken
by not defining the language they used.
Neither GCC nor Clang infer the language based on the driver name which means
`self.defines` isn't populated correctly in compilers/cpp.py.
e.g.
```
$ echo "" | g++ -E -dM - | grep -i cplus
$ echo "" | g++ -x c++ -E -dM - | grep -i cplus
#define __cplusplus 201703L
```
Fix that by passing '-cpp -x LANGUAGE' as a first pass. If it fails, try
again without '-cpp -x LANGUAGE' as before, as its portability isn't
certain. We do '-cpp' because during testing, I found Fortran needs this,
although per below, I had to drop Fortran in the end and leave it to the
fallback (existing) path.
Without this change, a63739d394 is only
partially effective. It works if the system has injected Clang options
via /etc/clang configuration files, but not by e.g. patching the driver
(or for GCC there too).
Unfortunately, we have to wimp out for Fortran and fallback to the
old method because you need the language standard (e.g. -x f95).
Make the debug & error message strings consistent between the GCC and Clang probes.
Copy-paste error. Here, we're scraping pre-processor tokens, not checking
for the compiler type.
"PEP 667: Consistent views of namespaces" caused locals() to be
inconsistent between uses since it is now created afresh every time you
invoke it and writes to it are dropped. `sys._getframe().f_locals` is
equivalent but preserves writes (it doesn't create a new dict) and
unfortunately doesn't help at all as it's documented to be a private
implementation detail of CPython that "should be used for internal and
specialized purposes only".
Work around this by saving locals to a variable reference and both
passing it into runctx and reusing it in lookups of the result. This
works okay for both new and older versions of python.
Per the documentation for locals():
> The contents of this dictionary should not be modified; changes may
> not affect the values of local and free variables used by the
> interpreter.
So... lesson learned? :) This was introduced in commit
c34ee374a77fb2dffff90364506ac0cbbb1f00de; before that, we still used
locals() but only to pass local variables *in*.
Bug: https://github.com/python/cpython/pull/115153
We passed a wrapper hack for shutil.chown because some functionality
wasn't available in the stdlib. It was added in python 3.13 beta1, so
the tests fail when we actually test symlink handling.
Fixes failure to run test_install_subdir_symlinks_with_default_umask_and_mode
on python 3.13.
There are two issues:
1. has_header() wants just the header name without surrounding <>
or similar; it fails otherwise.
2. has_header() returns a tuple of two bools, where the first element
determines whether or not the header has been found. So use
that element specifically, otherwise the tuple will always evaluate
to true because it is not empty.
Fixes: 675b47b069 ("compilers: cpp: improve libc++ vs libstdc++ detection (again)")
* Ensure private directory exists for custom targets
Some custom target commands will expect the `@PRIVATE_DIR@` to already exist, such as with `make -C @PRIVATE_DIR@ ...`
* Prefer `exist_ok` over catching exception
* Explicitly look for 'OpenAL' with method: 'cmake'
This test was added for testing cmake depenencies,
so no other method must be accepted here, and
the spelling must match FindOpenAL.cmake.
* Resolve frameworks in IMPORTED_LOCATION
The IMPORTED_LOCATION property of CMake targets may contain macOS
framework paths. These must be processed into flags. By putting the
values in the list of targets, they will be processed as if they
appeared in INTERFACE_LINK_LIBRARIES.
When trying to get the version of a program, meson was previously
hardcoded to run the binary with `--version`. This does work with the
vast majority of programs, but there are a few outliers (e.g. ffmpeg)
which have an unusual argument for printing out the version. Support
these programs by introducing a version_argument kwarg in find_program
which allows users to override `--version` with whatever the custom
argument for printing the version may be for the program.
This does a couple of things:
1. Scrape the `Py_GIL_DISABLED` sysconfig var, which is the best way as of today
to determine whether the target interpreter was built with `--disable-gil`
2. link against the correct libpython
3. On Windows, work around a known issue in the python.org installer with a
missing define in `pyconfig.h`, which the CPython devs have said is unlikely
to be fixed since headers are shared between the regular and free-threaded
builds in a single NSIS installer.
This adds the `-quiet` option when invoking clang-tidy for the generated
`clang-tidy` target. (Note that the `clang-tidy-fix` target already does
so.)
This prevents messages like
```
Suppressed 1084 warnings (1084 in non-user code).
Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
```
from being repeated for every file, which drowns out the actual
warnings/errors from clang-tidy when more than a few files are
processed.
Also the tip about `-header-fileter` and `-system-headers` is not very
useful here because Meson doesn't currently provide a way to supply
these options to clang-tidy.
Even with `-quiet`, clang-tidy still prints a line like `1084 warnings
generated.` for each file.
--html-nested option is used to create a separate web page for each file and directory. Each of these web pages includes the contents of file with annotations that summarize code coverage.
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>
Preface: why are we doing this?
For reasons of cross-platform interop, the Lix team is strongly
considering switching to build on a case sensitive filesystem in the
macOS installation, since otherwise storing case overlapping filenames
is busted and requires very very bad hacks:
https://git.lix.systems/lix-project/lix/issues/332
What's wrong:
Command line: `clang++ '/nix/temp/meson/b d01bff197e/meson-private/tmpjqid64j1/testfile.cpp' -o '/nix/temp/meson/b d01bff197e/meson-private/tmpjqid64j1/output.exe' -O0 -fpermissive -Werror=implicit-function-declaration -F/nix/store/qa92ravmclyraw7b46cz3q3m834mmbw9-apple-framework-OpenAL/Library/Frameworks -framework openal` -> 1
stderr:
ld: framework not found openal
clang-16: error: linker command failed with exit code 1 (use -v to see invocation)
Why is that happening:
$ ls /nix/store/qa92ravmclyraw7b46cz3q3m834mmbw9-apple-framework-OpenAL/Library/Frameworks
OpenAL.framework
So the test was relying on case insensitive fs, which is not a reliable
assumption on all macOS installations (since weird people like us can
set their fs to case sensitive!).
`boost_root` doesn't work if lib and include are in different directories like in the `nix` `boost` package.
The `prefix` checking could probably be removed, in 2019 conan (the
reason why the check was added) had `libdir` and `includedir` in its
generated pkg-config file
https://www.github.com/mesonbuild/meson/issues/5438#issuecomment-498761454
If there's no return then boost isn't found for some reason, further
logic is unnecessary in any case if direct paths are passed.
`roots += [Path(boost_lib_dir), Path(boost_inc_dir)]` did not work
In large monolithic codebases with many intertwined shared libraries, test
serialization can cause configuration times to balloon massively from a single
test() invocation due to concatenating the same paths many times over.
This commit adds an initial set in which all dependencies on a test target are
stored before their paths are constructed to form the test target's
LD_LIB_PATH. In testing on a particularly large codebase, this commit reduced
total configuration time by a factor of almost 8x.
When configuring a 'meson' or 'cmake@' style file,
add a case for escaped variables using matched pairs of
`\@` i.e. `\@foo\@ -> @foo@`.
The match for @var@ has been amended with a negative lookbehind
to ensure that any occurrances of `\@foo@` are not evaluated to
`\bar`.
The previous behaviour, matching `\@` and escaping only that character,
had undesirable side effects including mangling valid perl when
configuring files.
Closes: https://github.com/mesonbuild/meson/issues/7165
This fixes the unit test `TestAllPlatformTests.test_noop_changes_cause_no_rebuilds`,
when run with an `nm` binary from `cctools-port` (as shipped by conda-forge, see
https://github.com/conda-forge/cctools-and-ld64-feedstock).
It also addresses the issue discussed in https://github.com/mesonbuild/meson/discussions/11131,
and this build warning:
```
[48/1383] Generating symbol file scipy/special/libsf_error_state.dylib.p/libsf_error_state.dylib.symbols
WARNING: ['arm64-apple-darwin20.0.0-nm'] does not work. Relinking will always happen on source changes.
error: arm64-apple-darwin20.0.0-nm: invalid argument --
```
as reported in scipy#20740.
The unit test traceback was:
```
> self.assertBuildRelinkedOnlyTarget('mylib')
E AssertionError: Lists differ: ['mylib', 'prog'] != ['mylib']
E
E First list contains 1 additional elements.
E First extra element 1:
E 'prog'
E
E - ['mylib', 'prog']
E + ['mylib']
unittests/allplatformstests.py:1292: AssertionError
```
The `nm` shipped by Apple yields the exact same results either way; the man page for `nm`
only lists the single-character form so this seems preferred either way.
Cargo.lock is essentially identical to subprojects/*.wrap files. When a
(sub)project has a Cargo.lock file this allows automatic fallback for
its cargo dependencies.
The Python Limited API support that was added in 1.2 had
special handling of Windows, but the condition to check for
Windows was not correct: it checked for MSVC and not for
the target's OS. This causes mingw installations to not have
the special handling applied.
This commit fixes this to check explicitly for Windows.
This is in preparation for a future commit which makes it
possible for a PythonPkgConfigDependency to be used in a
context where previously only a PythonSystemDependency would
be used.
Based on the example in GH issue #13167, the limited API test has been
extended with a test to load the compiled module to ensure it can be
loaded correctly.
New people that want to use Meson for building Python extensions most
probably will read Python module docs first. Direct them to meson-python
and suggest to set `python.install_env=auto`.
Instead of invoking javac for every .java file, pass all of the sources
for a jar target to a single javac invocation. This massively improves
first compilation time and doesn't meaningfully affect incremental builds
(it can even be faster in some cases).
The old approach also had issues where files would not always get recompiled
even though they should, necessitating a clean rebuild in order to see changes
reflected in the build output.
Multiple invocations seem to only make sense if:
- issues with files not getting flagged for rebuild are investigated and fixed
- something like the javaserver buildtool from openjdk sources is used
instead of directly spawning javac processes
- the amount of java files per jar is so large that it is faster to compile
several files one by one than to compile all the files at once (batching may
still make sense to get a reasonable balance)
Sam James
Renan Lavarec
Eli Schwartz
Barnabás Pőcze
Tristan Partin
Scott Kyle
Kai Pastor
Dudemanguy
Ralf Gommers
TheHillBright
Mark A. Tsuchida
Tomas Popela
Walkusz
Jade Lovelace
Artturin
Campbell Jones
Matt Jolly
Charles Brunet
Daan De Meyer
Sebastian Wick
Rohit Goswami
Xavier Claessens
Jussi Pakkanen
Andrew McNulty
John Wiele
Emil Melnikov
Mis012