These do not go into the command line, and therefore do not matter
for the purpose of avoiding unnecessary rebuilds after meson is
rerun. However, they complicate the task of finding differences
between build lines across meson reruns.
So take the easy way out and sort everything after | and ||.
With this change, there is absolutely no change in QEMU's 40000-line
build.ninja file after meson is rerun.
There are two bugs here, first is that we open coded the output args,
instead of using the compiler method. The second is that rust args are
not passed down to the backend invocation.
Using the std option, so now `rust_std=..` will work. I've chosen to use
"std" even though rust calls these "editions", as meson refers to
language versions as "standards", which makes meson feel more uniform,
and be less surprising.
Fixes: #5100
I've always found ninja reporting 'a meson_exe.py custom command'
unclear and confusing. Instead say we are invoking a custom command,
wrapped by meson, and why.
Don't stop generating STATIC_LINKER rules at the first MachineChoice
which isn't available (i.e. generate a STATIC_LINKER rule, even if
STATIC_LINKER_FOR_BUILD isn't needed)
Also warn about internal errors which lead to non-existent rule
references, rather than exploding with a KeyError.
This allows the NINJA environment variable to support all the Windows special
cases, especially allowing an absolute path without extension.
Based on a patch by Yonggang Luo.
Fixes: #7659
Suggested-by: Nirbheek Chauhan <nirbheek@centricular.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
extra_paths only matter for the host machine if using an exe_wrapper.
However, because CustomTarget.for_machine is always MachineChoice.HOST,
they were computed unnecessarily in as_meson_exe_cmdline.
Defer computation of extra_paths until after we have found out if the
custom target executable is really for the host or the build machine,
so that we can use exe_for_machine; for_machine then becomes unused
and can be removed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Exceptions raised during subproject setup were ignored.
- Allow c_stdlib in native file, was already half supported.
- Eliminate usage of subproject variable name by overriding
'<lang>_stdlib' dependency name.
The lambda in NinjaBuildElement.write is quite expensive, totalling 0.3s
just to do a couple function calls. Since it is used just once, simply
inline it.
On a QEMU build, the total time spent in write from this series goes from
5.321s to 3.238s, though part of it can be attributed to previous patches.
Optimize the regular expression so that the variable expansion part
always ends up in group 1, and the trailer after the variable is discarded
in the same match. Do not use re.sub to remove braces, and do not bother
building the expanded command, just adjust the estimated length on the fly.
functools.reduce is extremely slow, so I am keeping ' '.join(chunk).
On a QEMU build the time spend in the function goes from 1.072s to 0.757s.
Use regular expressions to quickly weed out strings that require quoting
On a QEMU build the time spent in ninja_quote goes from 1.978s to 1.281s,
with str.replace being kicked completely out of the profile.
Without the parenthesis, the command evaluates to `[]` if
`use_llvm_cov` is `False`.
Also fix tests to actually check whether or not coverage reports are
generated.
Fixes https://github.com/mesonbuild/meson/issues/7553
otherwise we are getting errors like:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/mesonmain.py", line 131, in run
return options.run_func(options)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 245, in run
app.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 159, in generate
self._generate(env)
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/msetup.py", line 215, in _generate
intr.backend.generate()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 518, in generate
self.generate_coverage_rules()
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 991, in generate_coverage_rules
self.generate_coverage_command(e, [])
File "/usr/local/lib/python3.6/dist-packages/mesonbuild/backend/ninjabackend.py", line 975, in generate_coverage_command
for compiler in target.compilers.values():
AttributeError: 'RunTarget' object has no attribute 'compilers'
This extends the 109 generatecode test case to also define a test, so
coverage can really detect something.
Since the CompileArgs class already needs to know about the compiler,
and we really need at least per-lanaguage if not per-compiler
CompilerArgs classes, let's get the CompilerArgs instance from the
compiler using a method.
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.
Jussi Pakkanen
Dylan Baker
Paolo Bonzini
Alexander Neumann
Daniel Mensinger
Jon Turney
Martin Storsjö
Nirbheek Chauhan
Michael Hirsch
Xavier Claessens
Marcel Hollerbach
Cary Converse
Dan Kegel
georgev93