First of all, I'd like compilers and other modules that environment.py
currently imports to be able to take these without creating
hard-to-follow module cycles.
Second of all, environment.py's exact purpose seems a bit obscured.
Splitting the data types (and basic pure functions) from the more
complex logic that infers that data seems like a good way to separate
concerns.
This allows the person running configure (either a developer, user, or
distro maintainer) to keep a configuration of where various kinds of
files should end up.
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.
Previously, the default option string was compared to the actual project
option that has been converted to the proper type. This lead to messages
like 'Option x is: true [default: true]'.
Fixes#4806.
* Fixed spelling
* Merged the Buildoptions and Projectinfo interpreter
* Moved detect_compilers to Environment
* Added removed test case
* Split detect_compilers and moved even more code into Environment
* Moved set_default_options to coredata
* Small code simplification in mintro.run
* Move cmd_line_options back to `environment`
We don't actually wish to persist something this unstructured, so we
shouldn't make it a field on `coredata`. It would also be data
denormalization since the information we already store in coredata
depends on the CLI args.
Not need to catch exceptions in dependency_fallback(), it's already
handled in do_subproject(). This ensure subproject errors are handled
the same way when doing dependency() fallback and when doing
subproject().
If a configure_file has an install_dir set, the supported install
argument is ignored, while this should have actually higher priority
than the install_dir itself.
Also check that correct types are used for `install` and `install_dir`.
Add test to verify this.
Fixes#3983
Building a cross compiler (`build == host != target`) is not cross
compiling. As such, it doesn't make sense to handle it under
`is_cross_build`.
(N.B. Building a standard library for a cross compiler would require
cross compiling, but Meson has support to do such a thing as part of a
compiler build currently.)
It is possible that the subproject has been downloaded already, in that
case there is no reason to not use it. If the subproject has not been
downlaoded already it will fail do_subproject().
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.
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.
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).
Paolo Bonzini
John Ericson
Jussi Pakkanen
John Ericson
Dylan Baker
Daniel Mensinger
Nirbheek Chauhan
Michael Hirsch, Ph.D
Nicolas Schneider
Jan Tojnar
Xavier Claessens
Marco Trevisan (Treviño)
Jon Turney
Stian Selnes