These compilers are available in MinGW and can be built on macOS.
More interestingly, `gcc` is a wrapper around `clang` on macOS, so we
will detect the compiler type incorrectly on macOS without this.
It's only useful to use those when you have to override include dirs
or library paths by appending them from various sources according to
the priority order, or if the compiler args need to be converted from
Unix/GCC-style to native (MSVC, for instance) style.
Sanity checks match neither of these.
Closes https://github.com/mesonbuild/meson/issues/1351
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
Use a single check for both cases when we have includes and when we
don't. This way we ensure three things:
1. Built-in checks are 100% reliable with clang and on macOS since clang
implements __has_builtin
2. When the #include is present, this ensures that __builtin_func is not
checked for (because of MSYS, and because it is faster)
3. We fallback to checking __builtin_func when all else fails
prefix might define _GNU_SOURCE, which *must* be defined before your
first include of limits.h, so we must define it first.
There's not really any downsides to including limits.h after the
prefix.
Our "43 has function" test should also work with clang and icc on Linux,
so enable them. Also detect builtins with __has_builtin if available,
which is much faster on clang.
There is a feature request for the same with GCC too:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
If it's available, it's much much faster than doing #include
+ preprocess. Speeds up has_header checks by about 40% for me.
Currently, only Clang supports this
These two are also C-like sources, so don't ignore them in
backends/ninjabackend.py:generate_target() when we call
is_source() on the list of generated sources for that target.
Closes#1318
And fix the list of supported file suffixes, and use .f90 for all
fortran tests since ifort, the Intel Fortran compiler ignores files
ending with .f95, .f03, and .f08
Compiler versions 15.0 and later actually ignore invalid values for the
-std= option unless `-diag-error 10159` is passed, so we need to put
that in the unit test.
I have tested this with versions 14.0.3, 15.0.6, 16.0.4, and 17.0.1.
Would be great if someone could test with 13.x.y
Added IntelCompiler, IntelCCompiler and IntelCCompiler.
environments.py has been changed to detect icc and icpc.
ninjabackend changed for proper pch generation.
ICC 17.0.0 does not support C++13 (that's why default arguments tests fails).
Test 25 object extraction fails due to some unescaped whitespaces.
Some test with vala fail because of successful build, although they
should fail, as warning do not exit with failure.
Since we're checking for the existence of a header, just running the
preprocessor is enough. According to my benchmarks, doing this makes the
test roughly 2x faster.
I'm sure this will be useful for other checks too in the future.
This shaves off 7% on the configure time for glib on my machine.
This also fixes the issue that we had earlier where you had to specify
any extra headers needed to resolve symbols in the header being checked
for with `prefix`.
This avoids us having no compilers at all for targets that are composed
entirely of objects with no sources.
Now we will always have a compiler for a target even if it is composed
entirely of objects generated with custom targets unless it has
completely unknown sources.
When doing a compile-only self.compile() check, cl.exe expects an output
file of type *.obj, and passing it `output.exe` makes it write the
compiled object to `output.exe.obj`. Detect when we're doing
a compily-only check and change the suffix ourselves.
This is fine most of the time, but fails when you need to inspect the
compiled file manually.
Also store stdout/stderr on the returned object.
Check if the compiler prefixes an underscore to global symbols. This is
useful when linking to compiled assembly code, or other code that does
not have its C symbol mangling handled transparently by the compiler.
C symbol mangling is platform and architecture dependent, and a helper
function is needed to detect it. Eg: Windows 32-bit prefixes underscore,
but 64-bit does not. Linux does not prefix an underscore but OS X does.
Nirbheek Chauhan
Rodrigo Lourenço
Jussi Pakkanen
Mike Sinkovsky
Philipp Geier
Igor Gnatenko
Matthias Klumpp
Elliott Sales de Andrade