In commit 83a973ca04 a bunch of strange
changes were made, that were not even tested. Make sure people get the
correct command for running coverage targets.
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.
Meson will implicit rpaths when *.so/*.dll/etc. files are injected onto
the link line from pkg-config and (now) cmake dependencies.
Extend the "prebuilt shared" tests to test that these are added.
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>
Commit 191449f608 has numerous issues, and
being completely invalid yml syntax was just the tip of the iceberg.
In this case, it fails the github schema, which requires that env be
adjunct to a job or step definition, rather than its own thing. It did
not even make sense in context, since the purpose of the variable is to
modify brew.
Fixes: #12644Fixes: #12681
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.
Especially relevant for users of Ubuntu 22.04 which has packages for
Qt 6.2 and Meson 0.61.
a606ce22e ("Add support for Qt 6.1+", 2022-01-08)
d68a0651e ("qt module: also prefer the changed name scheme for the tools", 2022-02-09)
CLion was not mentioned in the list of IDE integrations. This commit adds it, also
adds a “3rd party" prefix to the Meson Syntax Highlighter plugin to indicate that it doesn't come from JetBrains, and sorts the list alphabetically.
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
```
git worktrees are frequently a handy tool to use. This glob pattern
asserts an error if the same named directory appears more than once,
which it will -- once per worktree -- but only because it is globbing
the entire project root, even though it should always only exclusively
care about files in `test cases/`. So just glob correctly, and then I
can run the testsuite locally again.
Fixes crash when running the tests and yasm is installed, but nasm is
not. When printing the compilers at early startup in
run_project_tests.py, we try to detect the nasm compiler, which in this
case turns out to be yasm, and its exelist assumes that the meson
command is set.
Fixes#12662
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.
Dylan Baker
Eli Schwartz
andy5995
Fabian Groffen
Sam James
Stas Sergeev
Alyssa Ross
Peter Urban
Roger Sanders
Jonathon Anderson
L. E. Segovia
Simon Ser
izimuth
Valeri
byteblob
Tamás Bálint Misius
Charles Brunet
Chris Mayo
Erik Bråthen Solem
Marina.Kalashina
wrvsrx
Sergey Vlasov
Denis Drakhnia