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.
GENERATED files can be used as dependencies for other targets, so it's
misguided (at best) to filter them with a blunt whitelist.
However, there does exist an extension that needs to be skipped: on Windows +
MSVC, CMake will by default try to generate a Visual Studio project, and
there dependencies with no inputs are instead tied to a dummy .rule
input file which is created by the generation step. The fileapi will
still report those, so it will cause Meson to bail out when it realises
there's no such file in the build tree.
Fixes#11607
* Vala: depend on gresources
Valac uses gresource at compile time to look up .ui files
* Automatically pass `--gresourcesdir` to valac
* gnome.compile_resources: clean up duplicate paths better
* Add a test for improved gresouce handling
For Clang, we now pass -D_GLIBCXX_DEBUG=1 if debugstl is enabled, and
we also pass -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_DEBUG.
Per https://discourse.llvm.org/t/building-a-program-with-d-libcpp-debug-1-against-a-libc-that-is-not-itself-built-with-that-define/59176/3,
we can't use _LIBCPP_DEBUG for older Clang versions as it's unreliable unless
libc++ was built with it.
We choose MODE_DEBUG for stldebug while building with assertions will do
MODE_EXTENSIVE.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
None of the options set here affect ABI and are intended for detecting constraint
violations.
For GCC, we simply need to set -D_GLIBCXX_ASSERTIONS.
For Clang, the situation is far more complicated:
* LLVM 18 uses a 'hardened mode' (https://libcxx.llvm.org/Hardening.html).
There are several levels of severity available here. I've chosen
_LIBCPP_HARDENING_MODE_EXTENSIVE as the strongest-but-one. The strongest
one (_DEBUG) doesn't affect ABI still but is reserved for stldebug.
* LLVM 15 uses a similar approach to libstdc++ called '_LIBCPP_ENABLE_ASSERTIONS'
Note that LLVM 17 while in development had fully deprecated _LIBCPP_ENABLE_ASSERTIONS
in favour of hardened, but changed its mind last-minute: https://discourse.llvm.org/t/rfc-hardening-in-libc/73925/4.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Standard include paths need to be added to resolve STL and platform
headers. Additionally, compiler args need to be separated by spaces, not
semicolons, in order to be recognised.
Nvcc doesn't support `-MQ` flag, so we have to manually escape cuda
target name.
This commit escape `$out` to `$CUDA_ESCAPED_TARGET`, so now we can just
use `-MT` flag in nvcc to generate header dependencies.
This reverts commit 53ea59ad84.
This breaks at least:
- frameworks/17 mpi
- frameworks/30 scalapack
The problem is that openmpi's pkg-config emitted link arguments
includes:
```
-Wl,-rpath -Wl,/path/to/libdir
```
The deduplication logic in meson doesn't contain sufficient information
to tell when the compiler is passing an argument that requires values,
and definitely cannot tell when that argument is split across argv. But
for arguments that *can* do this, it is not possible to deduplicate a
single argument as standalone, because it is not standalone.
The argument for deduplicating rpath here was that if you have multiple
dependencies that all add the same rpath, the Apple ld64 emits a
non-fatal warning "duplicate -rpath ignored". Since this is non-fatal,
it's not a major issue. A major issue is when builds fatally error out
with:
```
FAILED: scalapack_c
cc -o scalapack_c scalapack_c.p/main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,--start-group /usr/lib64/libscalapack.so /usr/lib64/liblapack.so /usr/lib64/libblas.so -Wl,-rpath -Wl,/usr/lib64 -Wl,/usr/lib64 -Wl,--enable-new-dtags /usr/lib64/libmpi.so -Wl,--end-group
/usr/libexec/gcc/x86_64-pc-linux-gnu/ld: error: /usr/lib64: read: Is a directory
```
Nirbheek Chauhan
Ole André Vadla Ravnås
Sam James
Charles Brunet
Ralf Gommers
H. Vetinari
Eli Schwartz
Dylan Baker
Albert Tang
Fabian Groffen
Stas Sergeev
Alyssa Ross
Peter Urban
Roger Sanders
Jonathon Anderson
L. E. Segovia
Simon Ser
Valeri
byteblob
Tamás Bálint Misius
Erik Bråthen Solem
wrvsrx
Sergey Vlasov
Denis Drakhnia