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).
It is a common idiom to look for a function or a specific type or
a header in various locations/libraries, and it can be confusing to
see the (seemingly) identical compiler check being done multiple
times.
Now we print the dependencies being used when a compiler check is run
Before:
Checking for function "fbGetDisplay": NO
Checking for type "GLeglImageOES": YES
Checking for function "asinh": YES
After:
Checking for function "fbGetDisplay" with dependency egl: NO
Checking for type "GLeglImageOES" with dependencies glesv2, gl: YES
Checking for function "asinh" with dependency -lm: YES
If a subproject is not required and fails during its configuration, the
parent project continues, but should not include any target or state set
by the failed subproject. This fix ninja still trying to build targets
generated by subprojects before they fail in their configuration.
The 'build' object is now per-interpreter instead of being global. Once
a subproject interpreter succeed, values from its 'build' object are
merged back into its parent 'build' object.
When dependency(), find_library(), find_program(), or
python.find_installation() return a not-found object and disabler is
true, they return a Disabler object instead.
If builddir and sourcedir have different drive letters, a relative path
doesn't exist, and os.path.relpath fails with a ValueError exception.
This just fixes the places which are hit by test cases in a simple-minded
way. There are several other uses of os.path.relpath(), which might be
suspect.
Fixes Issue #4323.
The check to see if a call to configure_file() overwrites the output of
a preceding call should perform the substitution for the output file
before doing the check.
Added tests to ensure the proper behaviour.
Instead of just putting these together in the interpreter, put them
together in `environment.py` so Meson's implementation can also better
take advantage of them.
meson.add_dist_script, introduced in #3906, did not accept any arguments
other than script name. Since all other meson.add_*_script methods
do accept args, this makes the dist script accept them as well.
It's fairly common on Linux and *BSD platforms to check for these
attributes existence, so it makes sense to me to have this checking
build into meson itself. Autotools also has a builtin for handling
these, and by building them in we can short circuit cases that we know
that these don't exist (MSVC).
Additionally this adds support for two common MSVC __declspec
attributes, dllimport and dllexport. This implements the declspec
version (even though GCC has an __attribute__ version that both it and
clang support), since GCC and Clang support the MSVC version as well.
Thus it seems reasonable to assume that most projects will use the
__declspec version over teh __attribute__ version.
Fixes:
meson.build:6:0: ERROR: Uncomparable version string 'unknown'.
This was previously partially fixed in a8694f4b, which only fixed it
for cached fallback dependencies.
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
Allowing to use the new "feature" option type and allowing not to fail
on subproject if it is not necessary to fail.
By default subprojects are "required" so previous behaviour is not
changed.
Fixes#3880
The fallback to compilers.base_options was done after optname is changed
to have subproject prefix. Simplify the code by looping over all
dictionaries and only keep user_options separate because that one is
special.
Earlier, we would replace the subproject option with the parent
project's option, which is incorrect if the types are not the same.
Now we retain the subproject's option and print a warning. It's not
advisable to issue an error in this case because subproject option
yielding is involuntary for the parent project (option names can match
because of coincidences).
Otherwise we get an error while checking the subproject version:
Uncomparable version string 'none'.
If the dependency was found as a not-found dependency in the
subproject and is not required, just take it.
Needs a `mock` kwarg to Interpreter to not do any parsing of build
files, but only setup the builtins and functions.
Also consolidate the documentation and data tests into one class.
Ninja buffers all commands and prints them only after they are
complete. Because of this, long-running commands such as `cargo
build` show no output at all and it's impossible to know if the
command is merely taking too long or is stuck somewhere.
To cater to such use-cases, Ninja has a 'pool' with depth 1 called
'console', and all processes in this pool have the following
properties:
1. stdout is connected to the program, so output can be seen in
real-time
2. The output of all other commands is buffered and displayed after
a command in this pool finishes running
3. Commands in this pool are executed serially (normal commands
continue to run in the background)
This feature is available since Ninja v1.5
https://ninja-build.org/manual.html#_the_literal_console_literal_pool
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
For some reason this was missing, but it should've always existed
since cc.find_library() returns an object that is internally an
ExternalDependency instance.
Instead of just printing the message in the exception, if it's
a MesonException, also print the file and the line number. If it's an
unknown exception, print the entire traceback so that we can pin-point
what the Meson bug causing it is.
Jon Turney
Dylan Baker
Jussi Pakkanen
Nirbheek Chauhan
Xavier Claessens
Christoph Behle
John Ericson
Jan Tojnar
Rafael Ávila de Espíndola
Alexis Jeandet
Thibault Saunier
GoaLitiuM
Patrick Griffis
Nirbheek Chauhan