Using scan-build gives the following warning:
"Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated."
This commit fixes this issue by adding the setup keyword to the meson command.
The .lcovrc file can contain several directives for genhtml, mostly
pertaining the visualisation of the generated HTML report. Passing the
config file to genhtml allows the user to customize their report.
Fixes#12863
Special notes:
- _nvcc_arch_flags is always called with exact arguments, no need for
default values
- min_driver_version has its args annotation loosened because it has to
fit the constraints of the module interface?
The min_driver_version function has an extensive, informative custom
error message, so leave that in place.
The other two functions didn't have much information there, and it's
fairly evident that the cuda compiler itself is the best thing to have
here. Moreover, there was some fairly gnarly code to validate the
allowed values, which we can greatly simplify by uplifting the
typechecking parts to the dedicated decorators that are both really good
at it, and have nicely formatted error messages complete with reference
to the problematic functions.
It is pretty trivial and more confusing when standalone, especially the
use of a sentinel "unknown" string as a standin for "this isn't one of
the allowed object types". Much easier to directly raise an error in the
fallthrough/else.
It is only ever invoked once. It has a statically known signature based
on how it's used, so there's no good reason to allow it to accept any
defaults -- and defaulting to None messes with type safety.
Saturate is always given, so don't claim it is only sometimes.
IfClauseNode is only ever initialized in such a way that this attribute
is immediately set to something valid. And attempting to access its
value when the value is None would be a pretty broken error anyway. The
assignment served no purpose, but did perform a frivolous runtime op in
addition to angering mypy's checks for implicit None.
An oddity: sys.stdout is statically defined as type TextIO instead of
TextIOWrapper, and thus doesn't have a .reconfigure method. This is
because they expect people to override sys.stdout with other objects,
which we do not do. Instead, assume it is always correct.
There are two final errors due to metaprogramming:
```
mesonbuild/mesonmain.py:196:13: error: Returning Any from function declared to return "int" [no-any-return]
mesonbuild/mesonmain.py:225:9: error: Returning Any from function declared to return "int" [no-any-return]
```
The add_arguments function is always called with a formatter in
mesonmain.py, and if it were not, then it would be incorrect when
calling argparse itself -- because formatter_class cannot be None, and
defaults to its own builtin one. This violates None-safety.
Instead of returning Optional, a state that is only possible during
`__init__` and which prevents mypy from knowing what it is safe to
assume it will get.
It's an improper object model, but was used to signal to a subclass that
self.traceparser did not exist. However, since it is always initialized
from self.cmakebin, we can just check that instead.
Since commit abc7e6af01 it is not possible
for this set of methods to return None, which was an odd thing to return
to begin with. Cease to annotate it as such.
It can be a list or a single dependency, but the same logic happens
either way. Instead of manually expanding the logic for both cases, just
convert it to a list as needed.
The type of quoting was changed in 522392e to one that is suitable for
use with cmd.exe on Windows. However, the documentation states that the
type of quoting in MESONINTROSPECT is compatible with shlex.split() and
elsewhere in the code, the same variable is still quoted with
shlex.quote(). As mostly identified in #12148, there are a few choices:
1. Use shlex.quote() consistently and support Python but not cmd.exe.
2. Use join_args and support cmd.exe but not Python.
3. Use join_args and support splitting through the mesonbuild Python library.
This commit implements the first option and reverts part of 522392e.
Regression testing is implemented in #12115.
Fixes#12148
This reverts commit 718c86a7d5.
We can't always use git to apply patches because they might actually
apply to a git submodule inside a git subproject, and git will not be
able to apply the patch in that case.
In 89146e84c9, a heuristic was introduced where
if libLLVMSupport is available as a static library, LLVM itself is assumed
to be availble as a static library as a whole.
This is unfortunately not the case at least on Gentoo and Arch Linux, where
a subsequent llvm-config call yields:
```
$ /usr/lib/llvm/17/bin/llvm-config --libfiles --link-static
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMTargetParser.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBinaryFormat.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMBitstreamReader.a
llvm-config: error: missing: /usr/lib/llvm/17/lib64/libLLVMRemarks.a
[...]
```
On Gentoo, where LLVM's static libraries are not included, we still have:
```
$ equery f llvm:17 | grep -i lib64/.*.a$
/usr/lib/llvm/17/lib64/libLLVMDemangle.a
/usr/lib/llvm/17/lib64/libLLVMSupport.a
/usr/lib/llvm/17/lib64/libLLVMTableGen.a
/usr/lib/llvm/17/lib64/libLLVMTestingAnnotations.a
/usr/lib/llvm/17/lib64/libLLVMTestingSupport.a
/usr/lib/llvm/17/lib64/libllvm_gtest.a
/usr/lib/llvm/17/lib64/libllvm_gtest_main.a
```
Therefore, testing for libLLVMSupport is insufficient. We now try libLLVMCore
instead, as that appears to only be installed when LLVM truly has static libraries
available. libLLVMCore is handled as a LLVM component which gives us some guarantee
this is supposed to be happening and not a fluke.
(Specifically, LLVM's llvm/lib/Support/CMakeLists.txt pays 0 attention to
-DLLVM_BUILD_LLVM_DYLIB and -DLLVM_LINK_LLVM_DYLIB, and is hence only affected
by -DBUILD_SHARED_LIBS, which LLVM upstream say is only to be used for development.
Therefore, with -DBUILD_SHARED_LIBS=OFF (as is recommended/the default) and
-DLLVM_BUILD_LLVM_DYLIB=ON, you will get a static libLLVMSupport, without it
indicating anything about the rest of your configuration.)
Closes: https://github.com/mesonbuild/meson/issues/12323
Fixes: 89146e84c9
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
CMake really prefers ON/OFF and in some cases, depending on how the condition
is written, ON/OFF vs other "truthy" (as far as CMake's lang supports) values
work differently. Just be safe and use ON/OFF.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
When hdf5 is built with cmake instead of autotools, it makes a number of
weird changes. What we care about in particular is that h5cc exists but
doesn't work -- it happily ignores -show and tries to compile stuff,
then leaves us with a dependency that has no libraries, and fails when
running `ninja`.
See: #12748
In recursive scanning, a script variable was overwritten that caused the
logic *intended* to make the embedded path be trimmed based on $DESTDIR,
to no longer apply. This resulted in embedding the staging path, but
only when install_subdir() was used instead of specifying each file as
the argument to install_sources.
Currently both print `Detecting linker via`, which can be confusing.
Clarifying this by printing "archiver" instead of "linker" for the
static linker/archiver
Xcode 14 has dropped the legacy build system, forcing us to use the
new one introduced in Xcode 9. The new system requires that we conform
to its "clean build folder" behavior, or clean operations fail.
CMake achieves this by setting other variables instead of SYMROOT, so
we follow that approach while retaining our current behavior as much
as possible.
Ref: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7730
Some backends may need to use its own target directories instead of
our default one. For this, introduce an optional argument "targetdir"
that will still use our default one when not specified.
Currently, the backend has "x86_64" hardcoded as the architecture,
which breaks cross compiling and compiling normally on arm64. Fix
this by setting it to the host machine's CPU architecture instead.
Python provides some nifty tools for mocking, without relying on
altering running code. We should use these to simplify the actual run
paths and move the complicated logic into tests.
xtools is in use on Gentoo Prefix x86_64 and ppc based Darwin installs.
Pick it up as a valid linker.
Since xtools is answering with a version to --version, as opposed to
ld64, detection of xtools in the ld64 handling block is not possible,
since --version already succeeded.
Bug: https://bugs.gentoo.org/868516
Bug: https://github.com/mesonbuild/meson/issues/10805
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
With LTO, the linker will re-execute the compiler and various warnings may
be emitted. We must therefore pass -Werror to the linker as well when -Werror
is enabled to capture these. This is only required / useful with LTO.
Closes: https://github.com/mesonbuild/meson/issues/7360
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
Stephan Lachnit
Esther Dalhuisen
Eli Schwartz
Charles Brunet
Sam James
Akihiko Odaki
Jouke Witteveen
Tristan Partin
Nirbheek Chauhan
Ole André Vadla Ravnås
Ralf Gommers
H. Vetinari
Dylan Baker
Albert Tang
Fabian Groffen
Stas Sergeev
Alyssa Ross
Peter Urban