After the previous commit, outfile is now passed down to lots of things
which don't use it, as they only create built statements, rather than
writing them out. Remove these unnecessary args.
Store the build statements and then write them all out, rather than
writing them out as we go.
Construct a NinjaBuildElement for the 'PHONY' target, rather than
writing it literally to the build.ninja file.
After the previous commit, outfile is now passed down to lots of things
which don't use it, as they only create rules, rather than writing them
out. Remove these unnecessary args.
Store the rules and then write them all out, rather than writing them
out as we go.
Store the rule broken down into parts which do and don't go into
rspfile, so we can construct either a rsp or non-rsp version of the
rule.
Instead of using the ___cmp__ method just straight up compare the two
values, since we've already converted numbers to ints and split
non-numeric seperators this is sufficient, and 4x faster
This uses an iterator instead of walking a list, which is roughly twice
as fast. This also does away with the pre-check on whether the list is
valid for converting to a dict, and instead handles the case of an
uneven number by catching another exception. This is preferable since
it's a fatal error anyway, so avoiding it in the non-fatal case is
preferable.
The cl.exe from Visual Studio 2010 and earlier report '80x86', not
'x86', for the architecture that the compiler supports. So, we ought
to check for that as well to see whether we are building for 32-bit x86.
The out-of-source build syntax for gcovr 4.2 is different compared to
previous versions and therefore an update was needed. In researching the
most appropriate solution it was found that any gcovr version older than
3.3 always resulted in 0% coverage. Because of this, rather than adding
an additional layer of logic, some already existing logic was modified
to ensure correct syntax for the new version, while versions older than
3.3 are flagged as not supported.
Closes mesonbuild#5089.
Setting this variable to contain additional commands to symlink shlib
aliases was removed in commit c0bf3e8d, so it's always unset now, and
thus does nothing.
This isn't safe given the way python implements default arguments.
Basically python store a reference to the instance it was passed, and
then if that argument is not provided it uses the default. That means
that two calls to the same function get the same instance, if one of
them mutates that instance every subsequent call that gets the default
will receive the mutated instance. The idiom to this in python is to use
None and replace the None,
def in(value: str, container: Optional[List[str]]) -> boolean:
return src in (container or [])
if there is no chance of mutation it's less code to use or and take
advantage of None being falsy. If you may want to mutate the value
passed in you need a ternary (this example is stupid):
def add(value: str, container: Optional[List[str]]) -> None:
container = container if container is not None else []
container.append(value)
I've used or everywhere I'm sure that the value will not be mutated by
the function and erred toward caution by using ternaries for the rest.
Currently this takes a return value, and in the error case sets it,
then has a separate if to hanle that. Instead just set the return
value in the error handler.
When the '-Wl,-rpath-link' option refers to several folders, we can
either use one single entry, like this:
-Wl,-rpath-link,/path/to/folder1:/path/to/folder2:/path/to/folder3
...or we can use multiple entries, like this:
-Wl,-rpath-link,/path/to/folder1
-Wl,-rpath-link,/path/to/folder2
-Wl,-rpath-link,/path/to/folder3
Because the '-rpath-link' requires full folder paths, using the one
single entry option can result in a very long argument.
While this shouldn't be a problem, at least *one* toolchain (the latest
version of the Tensilica toolchain for Xtensa processors) segfaults when
using arguments that are too long.
Because other toolchains might be affected and because using multiple
entries instead of a very long one doesn't seem to have any drawback,
this patch changes the arguments building logic to use multiple
'-Wl,-rpath-link' entries.
From (almost) all points of view, the Xtensa toolchain can be treated as
a regular GCC toolchain.
This patch adds very basic support so that, at least, meson does not
fail when trying to use "xt-xcc" (which makes it possible to use it
without problems).
Daniel Mensinger
Michael Hirsch, Ph.D
Jon Turney
Dylan Baker
Chun-wei Fan
Thibault Saunier
Richard Kjerstadius
Tamer Fahmy
Fernando Ramos
Jussi Pakkanen
Konstantin