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.
Can't just #include them and use them directly in unity builds. Inline
assembly is a thing, but it's not trivial and is deprecated with some
compilers. Just build them separately and link them in. Ideally the user
would then use LTO to ensure the same result.
Also C++ compilers can build .S assembly files. This wasn't noticed
earlier because most people were also using C compilers in their C++
projects and we would fall back to using the C compiler for building the
assembly files. Now we have a test for this.
This was trivial to add; except that we needed a new LLVM IR rule
because the compiler emits warnings if you pass any special arguments to
it such as include arguments or dependency arguments.
Closes#1089
Instead of adding it everywhere manually, create a wrapper called
mesonlib.Popen_safe and use that everywhere that we call an executable
and extract its output.
This will also allow us to tweak it to do more/different things if
needed for some locales and/or systems.
Closes#1079
We were checking for builtins explicitly like this because the ordinary
checks don't work for builtins at all. We do exactly the same check as
Autoconf and it doesn't work with Autoconf either (Autoconf is broken!)
So now we check for it in two ways: if there's no #include in prefix, we
check if `__builtin_symbol` exists (has_function allows checking for
functions without providing includes). If there's a #include, we check
if `symbol` exists.
The old method was causing problems with some buggy toolchains such as
MSYS2 which define some builtins in the C library but don't expose them
via headers which meant that `__builtin_symbol` would be found even
though `symbol` is not available.
Doing this allows people to always get the correct answer as long as
they specify the includes that are required to find a function while
also not forcing people to always specify includes to find a function
which is cumbersome.
Closes#1083
Unlike Linux and OS X, when a library is loaded, all the symbols aren't
loaded into a single namespace. You must fetch the symbol by iterating over
all loaded modules.
So, we shouldn't use /FORCE:UNRESOLVED since that is not what modules do
on Windows. Instead, we now do exactly what GModule does on Windows.
Also use `void` for functions that take no arguments.
We want compiler check arguments (-O0, -fpermissive, etc) to override
all other arguments, and we want extra_args passed in by the build file
to always override everything.
To do this properly, we must split include arguments out, append them
first, append all other arguments as usual, and then append the rest.
As part of this, we also add the compiler check flags to the
cc.compiles() and cc.links() helper functions since they also most
likely need them.
Also includes a unit test for all this.
Nirbheek Chauhan
Mike Sinkovsky
Philipp Geier
Igor Gnatenko
Jussi Pakkanen
Matthias Klumpp
Elliott Sales de Andrade