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.
Commit ff4a17dbef modified the version
requirements wrongly. AppleClangC should be the one with higher version
numbers. Exchange them to fix the check.
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
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
The compilers module is rather large and confusing, with spaghetti
dependencies going every which way. I'm planning to start breaking out
the internal representations into a mixins submodule, for things that
shouldn't be required outside of the compilers module itself.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
The Intel compiler is strange. On Linux and macOS it's called ICC, and
it tries to mostly behave like gcc/clang. On Windows it's called ICL,
and tries to behave like MSVC. This makes the code that's used to
implement ICC support useless for supporting ICL, because their command
line interfaces are completely different.
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
Instad of having special casing of threads in the backends and
everywehre else, do what we did for openmp, create a real
dependency. Then make use of the fact that dependencies can now have
sub dependencies to add threads.
Previously cross, but not native, external args were used. Then in
d451a4bd97 the cross special cases were
removed, so external args are never used.
This commit switches that so they are always used. Sanity checking works
just the same as compiler checks like has header / has library.
I recall that @jpakkane never wanted this, but @nirbheek did, but then
@nirbheek changed his mind.
I am fine either way except for the cross inconsistency that exists
today: There is no `c_preproc_args` or similar one can put in the cross
file, so no way to replicate the effect of CPPFLAGS during cross
compilation.
This patch creates an enum for selecting libtype as static, shared,
prefer-static, or prefer-shared. This also renames 'static-shared'
with 'prefer_static' and 'shared-static' with 'prefer_shared'. This is
just a refactor with no behavioral changes or user facing changes.
Currently we specialcase OpenMP like we do threads, with a special
`need_openmp` method. This seems like a great idea, but doesn't work
out in practice, as well as it complicates the opemp
implementation. If GCC is built without opemp support for example, we
still add -fopenmp to the the command line, which results in
compilation errors.
This patch discards that and treats it like a normal dependency,
removes the need_openmp() method, and sets the compile_args attributes
from the compiler.
Fixes#5115
Instead use coredata.compiler_options.<machine>. This brings the cross
and native code paths closer together, since both now use that.
Command line options are interpreted just as before, for backwards
compatibility. This does introduce some funny conditionals. In the
future, I'd like to change the interpretation of command line options so
- The logic is cross-agnostic, i.e. there are no conditions affected by
`is_cross_build()`.
- Compiler args for both the build and host machines can always be
controlled by the command line.
- Compiler args for both machines can always be controlled separately.
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
Instead of only doing a naive filesystem search, also run the linker
so that it can tell us whether the -F path specified actually contains
the framework we're looking for.
Unfortunately, `extraframework` searching is still not 100% correct in
the case when since we want to search in either /Library/Frameworks or
in /System/Library/Frameworks but not in both. The -Z flag disables
searching in those prefixes and would in theory allow this, but then
you cannot force the linker to look in those by manually adding -F
args, so that doesn't work.
It appears that LIB/LINK default to the host architecture if they can't
guess it from the first object. With the MSVC toolchain, resource files
are (usually) compiled to an arch-neutral .res format. Always
explicitly provide a '/MACHINE:' argument to avoid it guessing
incorrectly when cross-compiling.
Store the MSVC compiler target architecture ('x86', 'x64' or 'ARM' (this
is ARM64, I believe)), rather than just if it's x64 or not.
The regex used for target architecture should be ok, based on this list
of [1] version outputs, but we assume x86 if no match, for safety's
sake.
[1] https://stackoverflow.com/a/1233332/1951600
Also detect arch even if cl outputs version to stdout.
Ditto for clang-cl
Future work: is_64 is now only used in get_instruction_set_args()
This allows each implementation (gnu-like) and msvc to be implemented in
their respective classes rather than through an if tree in the CCompiler
class. This is cleaner abstraction and allows us to clean up the Fortran
compiler, which was calling CCompiler bound methods without an instance.
Because we need to inherit them in some cases, and python's
keyword-or-positional arguments make this really painful, especially
with inheritance. They do this in two ways:
1) If you want to intercept the arguments you need to check for both a
keyword and a positional argument, because you could get either. Then
you need to make sure that you only pass one of those down to the
next layer.
2) After you do that, if the layer below you decides to do the same
thing, but uses the other form (you used keyword by the lower level
uses positional or vice versa), then you'll get a TypeError since two
layers down got the argument as both a positional and a keyword.
All of this is bad. Fortunately python 3.x provides a mechanism to solve
this, keyword only arguments. These arguments cannot be based
positionally, the interpreter will give us an error in that case.
I have made a best effort to do this correctly, and I've verified it
with GCC, Clang, ICC, and MSVC, but there are other compilers like Arm
and Elbrus that I don't have access to.
It seems that clang-cl isn't quite compatible with cl in the way it handles
pch, and when the precompiled header is used, the pathname of the header is
needed, not just its filename.
This fixes test\common\13 pch with clang-cl
When invoked as clang-cl to compile, it doesn't emit cl-compatible D9002
warnings about unknown options, but fortunately also supports
-Werror-unknown-argument instead.
When invoked to link, and using LINK, it does emit cl-compatible LNK4044
warnings about unknown options.
Currently, ComplierHolder.determine_args() unconditionally adds the link
arguments to the commmand, even if we aren't linking, because it doesn't
have access to the mode (preprocess, compile, link) that
_get_compiler_check_args() will use.
This leads to command lines like:
'cl testfile.c /nologo /showIncludes /c /Fooutput.obj /Od kernel32.lib
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib comdlg32.lib advapi32.lib'
which clang-cl considers invalid; MSVS cl accepts this, ignoring the
unneeded libraries
Change from passing extra_args down to _get_compiler_check_args(), to
passing down a callback to CompilerHolder.determine_args() (with a bound
kwargs argument), so it can consult mode and kwargs to determine the args to
use.
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
Some compilers try very had to pretend they're another compiler (ICC
pretends to be GCC and Linux and MacOS, and MSVC on windows), Clang
behaves much like GCC, but now also has clang-cl, which behaves like MSVC.
This method provides an easy way to determine whether testing for MSVC
like arguments `/w1234` or gcc like arguments `-Wfoo` are likely to
succeed, without having to check for dozens of compilers and the host
operating system, (as you would otherwise have to do with ICC).
Replace several checks against GCC_MINGW or (GCC_MINGW, GCC_CYGWIN) with
is_windows_compiler instead, so that clang and other gcc-like compilers
using MinGW work appropriately with vs_module_defs, c_winlibs, and
cpp_winlibs.
Fixes#4434.
For PE/COFF it is not possible to allow undefined symbols, so do not
try to use the option to do so.
While gcc ld silently ignores it, this is not the case for the llvm
linker.
Fix#4415
* This helps with reproducibility on macOS in the same way
`$ORIGIN` improves reproducibility on Linux-like systems.
* This makes the build-tree more resilient to users injecting
rpaths via `LDFLAGS`. Currently Meson on macOS crashes when
a build-tree rpath and a user-provided `-Wl,-rpath` in
LDFLAGS collide, leading to `install_name_tool` failures.
While this still does not solve the root cause, it makes
the occurrence much less likely, as users will generally
pass absolute `-Wl,-rpath` arguments into Meson.
Dylan Baker