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.
This change fixes two usability issues with the genvslite project
generation. Unlike when using the full VS backend, under genvslite the
ProjectName property wasn't being set for generated projects. This means
projects end up being named according to the project files, which
includes suffixes like "@exe" in the solution, which is undesirable.
This change adds the ProjectName field in for genvslite projects, to
keep the naming consistent with projects under the VS backend.
Additionally, previously under genvslite, no projects were set to build
under any solution configuration by default. This is inconvenient, as
the user has to manually edit the build settings for each solution
configuration before they can compile at the solution level. There was a
note in the code to do something about this. This change enables
compilation at the solution level for the default startup project in the
solution, so the user can now just press F5 to build the solution and
run the default startup project, as they would typically expect.
On Linux many .so's are augmented with version information,
e.g. libxyz.so.1.2.3. CMake will happily refer to these versioned .so's
in its dependencies instead of libxyz.so (typically a symlink).
Unfortunately these versioned .so's aren't recognized as libraries by
the Backend's logic to produce build rpaths from library paths.
Fix this by recognizing any .so extension as sufficient reason to
produce a build rpath, not just if .so is the last extension.
Eli Schwartz
Charles Brunet
Sam James
Jouke Witteveen
Akihiko Odaki
Tristan Partin
Nirbheek Chauhan
Ole André Vadla Ravnås
Ralf Gommers
U2FsdGVkX1
H. Vetinari
Dylan Baker
Albert Tang
Fabian Groffen
Stas Sergeev
Alyssa Ross
Peter Urban
Roger Sanders
Jonathon Anderson