It's assumed that where we use DEPFILE in command or rspfile_content, it
can be quoted by quoting the ninja variable (e.g. $DEPFILE ->
'$DEPFILE')
This is nearly always true, but not for gcc response files, where
backslash is always an escape, even inside single quotes.
So this fails if the value of DEPFILE contains backslashes (e.g. a
Windows path)
Do some special casing, adding DEPFILE_UNQUOTED, so that the value of
depfile is not shell quoted (so ninja can use it to locate the depfile
to read), but the value of DEPFILE used in command or rspfile_content is
shell/response file quoted)
(It would seem this also exists as a more general problem with built-in
ninja variables: '$out' appearing in command is fine, unless one of the
output filenames contains a single quote. Although forbidding shell
metacharacters in filenames seems a reasonable way to solve that.)
(How does this even work, currently? Backslashes in the value of all
ninja variables, including DEPFILE were escaped, which protected them
against being treated as escapes in the gcc response file. And
fortunately, the empty path elements indicated by a double backslash in
the value of depfile are ignored when ninja opens that file to read it.)
Now that all command-line escaping for ninja is dealt with in the ninja
backend, escape_extra_args() shouldn't need to do anything.
But tests of existing behaviour rely on all backslashes in defines being
C escaped: This means that Windows-style paths including backslashes can
be safely used, but makes it impossible to have a define containing a C
escape.
We avoided having to get this right previously, as we'd always use a
response file if possible.
But this is so insane, I can't imagine it's right.
See also: subprocess.list2cmdline() internal method
In certain exotic configurations, the style of quoting expected in the
response file may not match that expected by the shell.
e.g. under MSYS2, ninja invokes commands via CreateProcess (which
results in cmd-style quoting processed by parse_cmdline or
CommandLineToArgvW), but gcc will use sh-style quoting in any response
file it reads.
Future work: The rspfile quoting style should be a method of the
compiler or linker object, rather than hardcoded in ninjabackend.
(In fact, can_linker_accept_rsp() should be extended to do this, since
if we can accept rsp, we should know the quoting style)
Rather than ad-hoc avoiding quoting where harmful, identify arguments
which contain shell constructs and ninja variables, and don't apply
quoting to those arguments.
This is made more complex by some arguments which might contain ninja
variables anywhere, not just at start, e.g. '/Fo$out'
(This implementation would fall down if there was an argument which
contained both a literal $ or shell metacharacter and a ninja variable,
but there are no instances of such a thing and it seems unlikely)
$DEPFILE needs special treatment. It's used in the special variable
depfile, so it's value can't be shell quoted (as it used as a filename
to read by ninja). So instead that variable needs to be shell quoted
when it appears in a command.
(Test common/129, which uses a depfile with a space in it's name,
exercises that)
If 'targetdep' is not in raw_names, test cases/rust all fail.
We need to count rsp and non-rsp references separately, which we need to
do after build statement variables have been set so we can tell the
difference, which introduces a bit of complexity.
Writing rsp files on Windows is moderately expensive, so only use them
when the command line is long enough to need them.
This also makes the output of 'ninja -v' useful more often (something
like 'cl @exec@exe/main.c.obj.rsp' is not very useful if you don't have
the response file to look at)
For a rule where using a rspfile is possible, write rspfile and
non-rspfile versions of that rule. Choose which one to use for each
build statement, depending on the anticpated length of the command line.
This is especially useful for Conan, where only the boost.pc
file is provided and manually setting BOOST_ROOT is not a
good solution since it is in a private cache directory.
See #5438
Simmilar to gcc, the list of pre-processor defines can be fetched with
`-dM -E` option. The way cpu_family is determined on linux relies on
this list.
Fixes incorrect value of cpu_family on linux, when crosscompiling:
```
CC="clang -m32" meson ./build
```
Signed-off-by: Yevhenii Kolesnikov <yevhenii.kolesnikov@globallogic.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Ideally we wouldn't need to have the default dict here and could just
rely on it being set as soon as project is called. There is a corner
case exercised by test case common/35 run program, which is that if a
FeatureNew or FeatureDeprecated is called to generate the meson version
it will be unset, to work around this I've changed the type from a dict
to a default dict with '' as the default value.
A better fix would probably be to store all of the
FeatureNew/FeatureDeprecated checks until the end, then evaluate them,
but for now this results in no loss of functionality, only more
functionality, even if it isn't prefect.
This gives the version that the feature was deprecated in, and doesn't
print the warning if the project supports versions of meson in which the
project wasn't deprecated.
The implementation of this function has changed enough that the name
doesn't really reflect what it actually does. It basically returns true
unless you're cross compiling, need and exe_wrapper, and don't have one.
The original function remains but is marked as deprecated.
This makes one small change the meson source language, which is that it
defines that can_run_host_binaries will return true in build == host
compilation, which was the behavior that already existed. Previously
this was undefined in build == host compilation.
This revert a part of #7020 because it was using gir_inc_dirs
before it is set. Properly fix typelib_includes instead that was working
only when g-i is a pkgconfig dependency.
```
File "mesonbuild/cmake/interpreter.py", line 293, in postprocess
'Unknown {}_std "{}" -> Ingoring. Try setting the project'
IndexError: Replacement index 2 out of range for positional args tuple
```
Now follows ios and other platform directory layouts. Moves from
separate android_$arch directories to every library containing a _$arch
suffix. e.g. libQt5Core_x86.a in a single directory.
in tree like dep structures with a lot of source: declarations, this can
result in a lot of presure on the source list. this saves ~3s out of 7s
in the interpretor stage in efl build.
Dan Kegel
Jon Turney
Michael Hirsch, Ph.D
Daniel Mensinger
Soapux
Phillip Johnston
TheQwertiest
georgev93
Alexander Neumann
Drew Reed
Yevhenii Kolesnikov
Dylan Baker
Xavier Claessens
Nirbheek Chauhan
Matthew Waters
Marcel Hollerbach
Eric Lemanissier