This has a bunch of nice features. It obviously centralizes everything,
which is nice. It also means that env is only re-read at `meson --wipe`,
not `meson --reconfigure`. And it's going to allow more cleanups.
This is PEP8 convention for a const variable. Also, make the type
Mapping, which doesn't have mutation methods. This means mypy will warn
us if someone tries to change this.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
Adds TemporaryDirectoryWinProof which calls windows_proof_rmtree() on
error.
Use instead of hacky error handling (which might shadow other OSError)
in Compiler.compile().
Since the current approach of demoting to the nearest C standard *might*
work, but might not. For projects like Glib that detect which standard
is used and fall back this is fine. For projects like libdrm that only
work with gnu standards, this wont. We're nog tusing a warning because
this shouldn't be fatal if --meson-fatal-warnings is used. Also demote a
similar message in IntelCl from warning to log.
And then update the choices in each leaf class. This way we don't end up
with another case where we implicitly allow an invalid standard to be
set on a compiler that doesn't have a 'std' setting currently.
As far as I can Tell, rust just handles this for us (it's always worked
with no special arguments from us). However, since we're going to add
support for base options for rust, we need to add the method.
When TemporaryDirectory() cleans up on __exit__ it sometimes throws
OSError noting that the dir isn't empty. This happens after the
first yield in this generator and leads to the exception being handled
which leads to a second yield.
contextlib.contextmanager() fails then since the function it wraps is only
allowed to yield once.
Fix this by not yielding again in the error case.
Fixes#7947
Using the std option, so now `rust_std=..` will work. I've chosen to use
"std" even though rust calls these "editions", as meson refers to
language versions as "standards", which makes meson feel more uniform,
and be less surprising.
Fixes: #5100
It is much easier to not try to parse options into complicated
structures until we actually collected all options: machine files,
command line, project()'s default_options, environment.
The implementation of the link variant was what should have been the
compiler variant, and there was no valid compiler variant, which meant
it was getting C code.
This abstraction is really useful, and most compilers could use it
(including D). It also will allow the Gnu mixins to work properly
without the CLikeCompiler in their mro.
So that every subclass doesn't have to reimplement it. Especially since
the Gnu implementation moved out of the CCompiler and into the
GnuLikeCompiler mixin
- Fixed using debug and optimization built-in options in MSVC.
- Fixed that VS backend does not create pdb files in release mode.
VS implicitly adds the debug fields if left out.
- Fix that it is possible to add debug info with ninja backend with
optimizations.
We do this by making the mixins inherit the Compiler class only when
mypy is examining the code (using some clever inheritance shenanigans).
This caught a bunch of issues, and also lets us delete a ton of code.
Every class needs to set this, so it should be part of the base. For
classes that require is_cross, the positional argument remains in their
signature. For those that don't, they just allow the base class to set
their value to it's default of False.
Currently we do some crazy hackery where we add extra properties to a
Popen object and return that. That's crazy. Especially since some of our
hackery is to delete attributes off of the Popen we don't want. Instead,
let's just have a discrete type that has exactly the properties we want.
1. Like with gcc's `ld`, also use the `group_start` code to create a
`--start-group`/`--end-group`
2. xc16 tricked into believing the 'link_whole' was about `--*-group`,
but it should use gcc's `--whole-archive` instead.
3. Not clear what the get_lib_prefix should really do, but for picolibc
it seems I want just `''`.
The problem with picolibc was that the `-l` would be prefixed to a lib
like `picolib/libm/libm.a`. Though of course the `-l` would be necessary
for just a plain `m` (that's what I assumed this would be used for).
I think this might need some clarification from the meson devs ;-)
If the architectures are taken from the output of "clang-cl --version",
we need to convert these names into names that the MSVC tools accept
as the -machine: parameter.
* Add preliminary support for the CompCert C Compiler
The intention is to use this with the picolibc, so some GCC flags are
automatically filtered. Since CompCert uses GCC is for linking, those
GCC-linker flags which are used by picolibc, are automatically prefixed
with '-WUl', so that they're passed to GCC.
Squashed commit of the following:
commit 4e0ad66dca9de301d2e41e74aea4142afbd1da7d
Author: Sebastian Meyer <meyer@absint.com>
Date: Mon Aug 31 14:20:39 2020 +0200
remove '-fall' from default arguments, also filter -ftls-model=.*
commit 41afa3ccc62ae72824eb319cb8b34b7e6693cb67
Author: Sebastian Meyer <meyer@absint.com>
Date: Mon Aug 31 14:13:55 2020 +0200
use regex for filtering ccomp args
commit d68d242d0ad22f8bf53923ce849da9b86b696a75
Author: Sebastian Meyer <meyer@absint.com>
Date: Mon Aug 31 13:54:36 2020 +0200
filter some gcc arguments
commit 982a01756266bddbbd211c54e8dbfa2f43dec38f
Author: Sebastian Meyer <meyer@absint.com>
Date: Fri Aug 28 15:03:14 2020 +0200
fix ccomp meson configuration
commit dce0bea00b1caa094b1ed0c6c77cf6c12f0f58d9
Author: Sebastian Meyer <meyer@absint.com>
Date: Thu Aug 27 13:02:19 2020 +0200
add CompCert to meson (does not fully work, yet)
* remove unused import and s/cls/self/
fixes the two obvious LGTM warnings
* CompCert: Do not ignore unsupported GCC flags
Some are safe to ignore, however, as per
https://github.com/mesonbuild/meson/pull/7674, they should not be
ignored by meson itself. Instead the meson.build should take care to
select only those which are actually supported by the compiler.
* remove unused variable
* Only add arguments once.
* Apply suggestions from code review
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
* Remove erroneous ' ' from '-o {}'.format()
As noticed by @dcbaker
* added release note snippet for compcert
* properly split parameters
As suggested by @dcbaker, these parameters should be properly split into multiple strings.
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
* Update add_compcert_compiler.md
Added a sentence about the state of the implementation (experimental); use proper markdown
* properly separate arguments
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
This type happened in https://github.com/mesonbuild/meson/pull/7432
and wasn't noticed because I didn't add a test for it. Rectified now.
If we don't specify the CRT, MSVC will pick /MT by default (!?) and
link to `libcmt.lib`. This actually *breaks* UWP because `libcmt.lib`
is not available by default when building for UWP.
Was noticed here: https://github.com/cisco/libsrtp/pull/505
Look for group-able flags with a single regex match, since we are already using
regexes for .so files. Also weed out flags other than -isystem very quickly
with a single startswith call.
On a QEMU build, the time spent in to_native goes from 2.279s to 1.322s.
The linker always args, as the name implies, should always be included. For
example, the AIX get_allow_undefined_link_args are a syntax error unless
the AIX get_linker_always_args are also used.
Meson calls `path/to/clang++ --version` to guess which build toolchain the
user has picked to build the source code. For the Qualcomm LLVM toolchain,
the output have an unusual output as shown below:
```
clang version 8.0.12
Snapdragon LLVM ARM Compiler 8.0.12 (based on llvm.org 7.0+)
Target: arm-unknown-linux-gnueabi
Thread model: posix
Repository: (ssh://git-hexagon-aus.qualcomm.com:...)
InstalledDir: /pkg/qct/software/llvm/release/arm/8.0.12/bin
```
Another unusual pattern is the output of `path/to/ld.qcld --version`:
```
ARM Linker from Snapdragon LLVM ARM Compiler Version 8.0.12
ARM Linker based on LLVM version: 8.0
```
The Meson logic is modified accordingly so that Meson can correctly
determine toolchain as "LLVM aarch64 cross-compiler on GNU/Linux64 OS".
This is the expected output of
`meson --native-file native_file.ini --cross-file cross_file.ini build/aarch64-debug/`:
```
...
C++ compiler for the host machine: ... (clang 8.0.12 "clang version 8.0.12")
C++ linker for the host machine: ... ld.lld 8.0.12
...
```
I made the mistake of always selecting the debug CRT for compiler
checks on Windows 4 years ago:
https://github.com/mesonbuild/meson/pull/543https://github.com/mesonbuild/meson/pull/614
The idea was to always build the tests with debugging enabled so that
the compiler doesn't optimize the tests away. But we stopped doing
that a while ago, and also the debug CRT has no relation to that.
We should select the CRT in the same way that we do for building
targets: based on the options.
On Windows ARM64, the debug CRT for ARM64 isn't always available, and
the release CRT is available only after installing the runtime
package. Without this, we will always try to pick the debug CRT even
when --buildtype=debugoptimized or release.
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
Causes spammy warnings from the linker:
ld: warning: -headerpad_max_install_names is ignored when used with -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES)
so: when building compile args, meson is deduplicating flags. When a
compiler argument is appended, a later appearance of a dedup'ed is going
to remove a earlier one. If the argument is prepended, the element
*before* the new one is going to be removed. And that is where the
problem reported in https://github.com/mesonbuild/meson/pull/7119 is
coming in. In the revision linked there, the order of replacement in the
prepend case was revesered.
With this patch, we restore this behaviour again.
The linker that comes with MSVC does not understand the /openmp flag.
This results in a string of
LINK : warning LNK4044: unrecognized option '/openmp'; ignored
warnings, one for each static_library linked with an executable.
Avoid this by only setting the linker openmp flag when the compiler is
not MSVC.
the previous optimizations from 4524088d38
were not relaly good, and not really scaleable, since only the lookup
was improved. However, the really heavy calls to remove have not been
improved.
With this commit we are refactoring CompilerArgs into a data structure
which does not use remove at all. This works that we are building a pre
and post list, which gets flushed into __container at some point.
However, we build pre and post by deduplicating forward. Later on, when
we are flushing pre and post into __container, we are deduplicating
backwards the list, so we are not changing behaviour here.
This overall cuts off 10s of the efl configuration time. Further more
this improves configure times on arm devices a lot more, since remove
does seem to be a lot slower there. In general this results in the fact
that __iadd__ is not within the top 5 of costly functions in
generate_single_complie.
Simmilar to gcc, the list of pre-processor defines can be fetched with
`-dM -E` option. The way cpu_family is determined on linux relies on
this list.
Fixes incorrect value of cpu_family on linux, when crosscompiling:
```
CC="clang -m32" meson ./build
```
Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Right now we hardcode -DNDEBUG as the value to be added for b_ndebug.
Which is a not the correct behavior for non C/C++ languages. By pushing
this back into the compiler classes we can change this for other
languages.
has_function() tries to link an example program using the function
to see if it is available, but with clang on 64bit Windows this
example always already failed at the compile step:
error: cast from pointer to smaller type 'long' loses information
long b = (long) a;
This is due to long!=pointer with LLP64
Change from "long" to "long long" which is min 64bit and should always
fit a pointer. While "long long" is strictly a C99 feature every
non super ancient compiler should still support it.
The builtin check had a special case that if a header was provided and
the function wasn't defined, it would ignore the builtin to avoid
non-functional builtins (for example __builtin_posix_memalign in MSYS2).
GCC 10 gained support for __has_builtin() which now skipps this check
and because __has_builtin(__builtin_posix_memalign) returns true the
non functional builtin is now reported as available.
To get the old behaviour back move the special case in front of the actual
availability check.
Fixes#7113
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
When doing a compile test with a testfile.c, ccache fails since the path is random.
So it's better to disable it, to avoid reporting this as a cache miss.
If no exe_wrapper is set in the meson cross file the exe_wrapper
object will be an instance of EmptyExternalProgram.
So, found is True and prorgram is an empty list.
This will cause meson to tun the compiler sanity check because
it checks only for self.is_cross and self.exe_wrapper being
not None.
I ran into that situation while cross compiling for ia32 on a
x64_64 host. The host had no ia32 userspace installed, so the
self test failed.
As workaround I currently set exe_wrapper to 'true'.
Signed-off-by: Richard Weinberger <richard@nod.at>
Clang supports the GCC -Og flag, but --optimization=g is not setting that. This is because Clang is referencing the clike_optimization_args, which does not define a flag for 'g'.
To address this, we'll mimic the GNU options instead of the C-like ones.
Fixes#6619
This should have worked before, but the inheritance order was backwards,
so we got the DCompiler before the GnuCompiler, and the base Compiler
methods overrode the Gnu methods.
Some compilers that act as linker drivers (dmd and ldc) need to split
arguments that GCC combines with , (ie, -Wl,-foo,bar -> -L=-foo -L=bar).
As such we need to detect that the previous argument contained -soname,
and not wrap that in a --start-group/--end-group
This modifies the shared library test to demonstrate the problem, with a
test case.
Fixes#6359
This is the argument to name the implib when using the Visual Studio
Linker. This is needed by LDC and DMD when using link.exe or
lld-link.exe on windows, and is really a linker argument not a compiler
argument.
DMD and LDC are a real pain to use as linkers. On Unices they invoke the C
compiler as the linker, just like meson does. This means we have to figure out
what C compiler they're using and try to pass valid arguments to that compiler
if the D compiler doesn't understand the linker arguments we want to pass. In
this case that means gcc or clang. We can use-the -Xcc to pass arguments
directly to the C compiler without dmd/ldc getting involved, so we'll use that.
This was never really true of the D compilers, it made them more
complicated than necessary and was incorrect in many cases. Removing it
causes no regressions on Linux, at least in our rather limited test
cases).
listify shouldn't be unholdering, it's a function to turn scalar values
into lists, or flatten lists. Having a separate function is clearer,
easier to understand, and can be run recursively if necessary.
the check for which files can be compiled are called again and again on
the same files over and over again. Caching this here shaves off 11s of
the build time of efl (which has grown in the last 3 versions to over 40
sec. again)
in order to deduplicate arguments as much as possible, we need to check
if a argument is already part of the list. Which is quite slow because
we are checking 3 lists for that.
In smaller projects this might be not of interested. However, in efl
things are quite "heavy", alone generating the ninja file took 40 sec..
16 sec. are spent in __iadd__ of CompilerArgs.
What this patch does to speed this all up is:
1. We only check if a element is in post when we know that it must be in
post same for pre.
2. the checks for if we already do contain a specific value are now done
via a dict, and not via the list.
This overall brings the time from 16 sec. spent in __iadd__ to 9 sec. in
__iadd__.
Another possible solution for all this is to have a internal structure
of CompileArgs of trees, so you have the "basic" layer of arguments
where the position does not matter. Additionally, you have two stacks of
lists, the pre stack and the post stack, duplicates can then be checked
when itereting, which would safe another ~4s in terms of efl. However, i
do not have time for this undertaking right now.
Emscripten does have a stand alone linker, wasm-ld. This patch adds the
linker, adds detection for the linker, and removes the IsLinkerMixin for
emscripten. This is a little more correct, and makes the code a lot
cleaner and more robust.
Emscripten has pthread support (as well as C++ threads), but we don't
currently implement them. This fixes that by adding the necessary code.
The one thing I'm not sure about is setting the pool size. The docs
suggest that you really want to do this to ensure that your code works
correctly, but the number should really be configurable, not sure how to
set that.
Fixes#6684
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
This gives consistent reporting of this error for all platforms.
Also, reporting this error when constructing the BuildTarget, rather
than discovering the problem during backend generation means that the
error is reported against with a location.
Instead of checking the compiler id inside the VisualStudioLikeCompiler
class, this creates two subclasses that each represent the divergent
behavior of the two compilers
* environment: Fix passing always args to a number of less common linkers
These are mostly (oops xilink) proprietary linkers I can't use for
various reasons.
Fixes: #6332
* Add intelfix from scivision.
* Ifort fix from scivision.
* PGI fix from scivision.
* Cuda fix from scivision.
* Fix linker passing for armclang.
this can be useful for if/elif where linker behaviors must be
considered.
For example, clang with "link" vs gcc with "ld.bfd" etc.
ci for compiler.get_linker_id() method
doc
add @FeatureNew check
Co-Authored-By: Daniel Mensinger <daniel@mensinger-ka.de>
intel compiler's defaults are different enough from MSVC and GNU
that it's necessary to set specific defaults for Intel compilers.
This corrects/improves behaviors initially addressed in b1c8f765fa
If a user passes -fuse-ld=gold to gcc or clang, they expect that they'll
get ld.gold, not whatever the default is. Meson currently doesn't do
that, because it doesn't pass these arguments to the linker detection
logic. This patch fixes that. Another case that this is needed is with
clang's --target option
This is a bad solution, honestly, and it would be better to use $LD or a
cross/native file but this is needed for backwards compatability.
Fixes#6057
Currently this is done at the instance level, but we need it at the
class level to allow compiler "lang" args to be gotten early enough.
This patch also removes a couple of instance of branch/leaf classes
providing their own implementation that is identical to the Compiler
version.
There are two awful things about CompilerArgs, one is that it directly
inherits from list, and there are a lot of subtle gotcahs with
inheriting from builtin types. The second is that the class allows
arguments to be passed in whatever order. That's bad. This also fully
annotates the CompilerArgs class, so mypy can type check it for us.
`from foo import` should be used sparingly because of namespace
pollution, especially since those names will be exported
unconditionally. For typing this is extra annoying because anytime
someone wants to use another symbol from the typing module they have to
add it to the import line. Use `import typing` to avoid all of this.
Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
This puts appropriate default options across buildtype for Intel and
Intel-Cl compilers, for C, C++ and Fortran. Prior to this PR, the
behavior of Intel compilers vs. GNUlike was not the same, in
particular, debug traceback available by default for GNUlike compilers
was not present with Intel compilers.
Since version 9.1, GCC provides support for the D programming language. Thus it
is easy to build a cross-compiler for D, such as aarch64-unknown-linux-gnu-gdc.
However to cross-compile a Meson project using D, using a cross build definition
such as the following is not enough:
```
[binaries]
d = '/path/to/aarch64-unknown-linux-gnu-gdc'
exe_wrapper = '/path/to/qemu-aarch64-static'
[properties]
needs_exe_wrapper = true
[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'cortex-a53'
endian = 'little'
```
Indeed, "exe_wrapper" is not be taken into account. Build will fail with:
```
Executables created by D compiler /path/to/aarch64-uknown-linux-gnu-gdc are not runnable.
```
This patch fixes this by reworking:
- detect_d_compiler() to properly get exe_wrapper and D compilers and detect the
one available.
- Dcompiler to properly handle exe_wrapper.
It would be very challenging if not futile to make has_function work for Fortran.
The meson.get_compiler('fortran').links() works very well instead.
As a reference, CMake's check_fortran_function_exists is completely broken in general.
This change raises a useful MesonException instead of giving bizarre errors.
These compilers invoke external linkers and have the appropriate .linker
property set. Therefore, BasicLinkerIsCompilerMixin appears to be
misplaced.
It used to work by chance, because BasicLinkerIsCompilerMixin failed to
override the get_allow_undefined_link_args method. The D compilers do
not provide their own get_allow_undefined_link_args, because they expect
to inherit it from Compiler, which simply delegates it to the linker.
Now that BasicLinkerIsCompilerMixin correctly overrides that method with
a stub, it broke compilers that relied on the buggy behavior.
Commit ff4a17dbef modified the version
requirements wrongly. AppleClangC should be the one with higher version
numbers. Exchange them to fix the check.
compiler.get_supported_arguments reports success for certain unsupported
flags when using the gnu C/ObjC, C++/ObjC++ compilers. This fix reads
the stderr on the has_arguments check to ensure the arguments really are
supported and not valid for the language selection
Now that the linkers are split out of the compilers this enum is
only used to know what platform we're compiling for. Which is
what the MachineInfo class is for
Instead of the DynamicLinker returning a hardcoded value like
`-Wl,-foo`, it now is passed a value that could be '-Wl,', or could be
something '-Xlinker='
This makes a few things cleaner, and will make it possible to fix using
clang (not clang-cl) on windows, where it invokes either link.exe or
lld-link.exe instead of a gnu-ld compatible linker.
Ifort can generate dependency information (.d files), it just does it
differently than GNU compilers do. This also fixes a bug caused by
adding the dependency generation commands to the GNULike class later in
this series.
We support 3 D compilers, DMD, LDC, and GDC. DMD is the reference
compiler, and LDC attempts to largely mirror it's command line usage.
GDC does not, it instead acts like GCC (which makes sense). The current
abstraction puts DMD behavior in the base D compiler and then overrides
then in the GnuDCompiler class.
This is messy, but it becomes more problematic when splitting the linker
and compiler abstractions apart.
I've opted to instead split the DCompiler class into two separate
classes. The DCompiler implements core D functinoality, and
DmdLikeCompilerMixin, which implements the DMD and LDC command line
arguments. I've then mxed that into the DmdDCompiler and LLVMDCompiler
classes, and mixed the GnuCompiler into the GnuDCompiler class to get
Gnu command line behavior.
To make Fortran tests useful on Windows, the library_type should default to static,
unless needed to specifically test shared. Shared Fortran libs on Windows for
non-Gfortran compilers is fragile requiring proprietary code syntax.
* PGI C++ PCH enable
PGI compilers support precompiled headers for C++ only.
The common/13 pch test passes if run manually with no spaces in the build path.
However, since Meson run_project_tests.py makes temporary build directories
with spaces in each tests, PGI --pch_dir can't handle this and fails.
So we skip the test for PGI despite it working for usual case with no-spaces
in build dir.
Note: it's fine to have spaces in full path for sourcedir, just no spaces in
relative path to builddir.
* doc
There are two problems, one is that it assumes -flto is the argument
to do LTO/WPO, which isn't true of ICC and MSVC (and presumably)
others. It's also incorrect because it assumes that the compiler and
linker will always be the same, which isn't necessarily true. You
could combine GCC with Apple's linker, or clang with link.exe, which
use different arguments.
Error example:
Code:
#include <locale.h>
int main () {
/* If it's not defined as a macro, try to use as a symbol */
#ifndef LC_MESSAGES
LC_MESSAGES;
#endif
}
Compiler stdout:
Compiler stderr:
In file included from /usr/include/locale.h:25,
from /tmp/tmpep_i4iwg/testfile.c:2:
/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
382 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
/tmp/tmpep_i4iwg/testfile.c: In function 'main':
/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void function [-Werror=return-type]
8 | }
| ^
cc1: some warnings being treated as errors
There is a pretty big error in here, trying to return a tuple
comperhension: (a for a in []) is not a tuple, it's a generator. This
has profound type annotations: generators don't support most tuple or
list methods, and they can only be iterated once. Beyond that tuples are
meant for heterogenous types, ie, position matters for types. I've
converted the output to a list in all cases.
Antonin Décimo