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
```
Anywhere we have that, we also have the Environment object, which is
just wrapped by the Interpreter methods anyway. This avoids inderections
that are unnecessary.
This should have been done in my earlier fix, but kinda forgot to test and
fix it there as well.
See https://github.com/mesonbuild/meson/pull/11733 for the discussion.
Fixes: 8284be813 ("dependencies/llvm: strip default include dirs")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
mypy will complain if backends.Backend has a lru_cache wrapped method,
but it is overridden in XCodeBackend with a method that isn't cached.
This is almost certainly a sign that we should be caching it here too
anyway. The generic backend cache was added years ago via an
intimidating commit f39d2cc3bf which
claims that it reduced call time from 60s to 0.000435s and that this was
specifically due to getting a coredata option every single time. This is
probably workload dependent, but getting an option is *not* nearly as
cheap as a throwaway function call.
Xcode does not recognize our private directories, nor does it ever
try to generate them. Instead, just import the build directories
for each swift dependency.
This fixes linking between swift targets when they are in their own
subdirectories, as they will have different build directories in that
case.
Dylan Baker
Eli Schwartz
Fabian Groffen
Sam James
Stas Sergeev
Alyssa Ross
Peter Urban
Roger Sanders
Jonathon Anderson
L. E. Segovia
Simon Ser
Valeri
byteblob
Tamás Bálint Misius
Charles Brunet
Erik Bråthen Solem
wrvsrx
Sergey Vlasov
Denis Drakhnia
Karol Herbst
Nicolas Werner
H. Vetinari
Albert Tang