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.
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.
ICC doesn't use the same -fprofile-generate/-fprofile-use that GCC and
Clang use, instead it has -prof-gen and -prof-use. I've gone ahead and
added the threadsafe option to -prof-gen, as meson currently doesn't
have a way to specify that level of granularity and GCC and Clang's
profiles are threadsafe.