We used to immediately try to use whatever exe_wrapper was defined in
the cross file, but some people generate the cross file once and use
it for several projects, most of which do not even need an exe wrapper
to build.
Now we're a bit more resilient. We quietly fall back to using
non-exe-wrapper paths for compiler checks and skip the sanity check.
However, if some code needs the exe wrapper, f.ex., if you run a built
executable using custom_target() or run_target(), we will error out
during setup.
Tests will, of course, continue to error out when you run them if the
exe wrapper was not found. We don't want people's tests to silently
"pass" (aka skip) because of a bad CI setup.
Closes https://github.com/mesonbuild/meson/issues/3562
This commit also adds a test for the behaviour of exe_wrapper in these
cases, and refactors the unit tests a bit for it.
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
* Fix flake8 whitespace reports
$ flake8 | grep -E '(E203|E221|E226|E303|W291|W293)'
./mesonbuild/coredata.py:337:5: E303 too many blank lines (2)
* Fix flake8 'variable assigned value but unused' reports
$ flake8 | grep -E F841
./mesonbuild/modules/gnome.py:922:9: F841 local variable 'target_name' is assigned to but never used
* Fix flake8 'imported but unused' reports
$ flake8 | grep F401
./mesonbuild/compilers/__init__.py:128:1: F401 '.c.ArmclangCCompiler' imported but unused
./mesonbuild/compilers/__init__.py:138:1: F401 '.cpp.ArmclangCPPCompiler' imported but unused
./mesonbuild/modules/__init__.py:4:1: F401 '..mlog' imported but unused
PR #3717 imports ARMCLANG compilers in __init__, but does not add them to
__all__, so they are not re-exported by the compilers package like
everything else.
* More details about flake8 in Contributing.md
Mention that Sider runs flake8
Suggest seting flake8 as a pre-commit hook
Paths provided to us by the user or by pkg-config can be (and must be)
assumed to be usable since they might not be usable standalone.
Closes https://github.com/mesonbuild/meson/issues/3832
Rather than storing in the cache of search paths the full list returned
from the compiler and having each call ignore the non-existent ones, remove
from the list all non-existent ones before returning to the caching function.
When find_library is used to find dependencies, meson checks all paths for
libraries with all prefixes that could match. This means that when we are
compiling with -m32 on a 64-bit system, meson will find 64-bit libraries and
assumes that they will work. Naturally that is not the case.
The obvious fix is to do a test link against those libraries, but the extra
wrinkle here is that we need to do a "whole link" so as to test the static
libs. A check with gcc+ld on linux shows that unless there are unresolved
symbols from the main.c file, the static library is never checked so we avoid
the error from an incompatible library.
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
All dependencies were using find_library, has_header, get_define, etc on
self.compiler assuming that it's a compiler that outputs and consumes
C-like libraries. This is not true for D (and in the future, for Rust)
since although they can consume C libraries, they do not use the
C ecosystem.
For such purposes, we now have self.clib_compiler. Nothing uses
self.compiler anymore as a result, and it has been removed.
On macOS, we set the install_name for built libraries to
@rpath/libfoo.dylib, and when linking to the library, we set the RPATH
to its path in the build directory. This allows all built binaries to
be run as-is from the build directory (uninstalled).
However, on install, we have to strip all the RPATHs because they
point to the build directory, and we change the install_name of all
built libraries to the absolute path to the library. This causes the
install name in binaries to be out of date.
We now change that install name to point to the absolute path to each
built library after installation.
Fixes https://github.com/mesonbuild/meson/issues/3038
Fixes https://github.com/mesonbuild/meson/issues/3077
With this, the default workflow on macOS matches what everyone seems
to do, including Autotools and CMake. The next step is providing a way
for build files to override the install_name that is used after
installation for use with, f.ex., private libraries when combined with
the install_rpath: kwarg on targets.
Added method concatenate_string_literals to CCompiler. Will concatenate
string literals.
Added keyword argument 'concatenate_string_literals' to Compiler.get_define.
If used will apply concatenate_string_literals to its return value.
Because vala is not listed in clike_langs, is_source(fname) is returning False
for Vala source files. Therefore, extract_all_objects() is completely empty
for Vala programs.
Fixes#791
Otherwise we can end up searching for the same library tens of times,
because pkg-config does not de-duplicate -lfoo args before returning
them.
We use -Wl,--start-group/end-group, so we do not need to worry about
ordering issues in static libraries.
Normally, people would just pass -fembed-bitcode in CFLAGS, but this
conflicts with -Wl,-dead_strip_dylibs and -bundle, so we need it as
an option so that those can be quietly disabled.
This checks not only for existence, but also for usability of the
header, which means it does a full compilation and not just
pre-processing or __has_include.
Fixes https://github.com/mesonbuild/meson/issues/2246
* mesonbuild/compilers/c.py: Make the `find_library` method more generic by allowing the user to supply the `code` for compiling and linking.
* mesonbuild/compilers/fortran.py: Use the methods inherited from `Compiler` base class where appropriate. Also reuse `CComiler` methods where applicable. This should be sufficient to get various compiler/linker arguments as well as to compile and link Fortran programs. This was tested with `gfortran` compiler, and while the other compilers ought to work for simple cases, their methods are primarily inherited from the base `FortranCompiler` class.
* test cases/fortran/10 find library/gzip.f90: Fortran module with some basic Fortran wrapper interfaces to `gzopen`, `gzwrite`, and `gzclose` C `zlib` functions.
* test cases/fortran/10 find library/main.f90: Fortran program using the `gzip` Fortran interface module to write some data to a gzip file.
* test cases/fortran/10 find library/meson.build: Meson build file for this test case. This demonstrates the ability to link the Fortran program against an external library.
GCC does not print a warning or error for unknown options if the options
are to disable warnings. Therefore, when checking for options starting
'-Wno-', also check the opposite enabling option. This fixes the case
where e.g. -Wno-implicit-fallthrough is incorrectly reported as supported
by gcc 5.4. To avoid missed warnings when using combinations of flags, such
as in test case "112 has arg", we limit the checking of for the positive
option to where the negative option is checked alone.
This patch exploits the information residing in ltversion to set the
-compatibility_version and -current_version flags that are passed to the
linker on macOS.
GNU LD does not use soname when linking a PE/COFF binary, so it makes no
difference, but it breaks when using the llvm linker (lld), which does
not support the soname flag when building PE/COFF binaries for Windows.
Fix#3179
Nirbheek Chauhan
Jon Turney
Bruce Richardson
Matthias Klumpp
Jussi Pakkanen
Vasu Penugonda
Christoph Behle
Paolo Bonzini
Xavier Claessens
Christoph Reiter
Matthew Krupcale
Jasper Lievisse Adriaanse
Martin Hostettler
Elliott Sales de Andrade
Tom Schoonjans
Marvin Scholz