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.
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.
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).
* coredata: store cross/native files in the same form they will be used
Currently they're forced to absolute paths when they're stored in the
coredata datastructure, then when they're loaded we de-absolute path
them to check if they're in the system wide directories. This doesn't
work at all, since the ninja backend will generat a dependency on a
file that is in the source directory unless the path was already given
as absolute. This results in builds being retriggereed forever due to
a non-existant file.
The right way to do this is to figure out whether the file is in the
build directory, is absolute, or is in one of the system paths at
creation time, and store that path as absolute. Then the code that
reads the file and the code that generates the dependencies in the
ninja backend just takes the computed list and there is no mismatch
between them.
Fixes#5257
* run_unittests: Add a test for correct native file storage
This tests the bug in #5257
This is the VS-specific part of the previous commit; the Visual Studio
backend was ignoring dependencies, add an AdditionalInputs element
similar to what add_custom_build does.
If find_program() returns a file from the source directory, anything
that uses it should add the file to the dependencies, so that they are
rebuilt whenever the script changes. Generator is not doing that.
While at it, I am doing two related fixes:
- Generator is not checking whther the generator actually was found,
resulting in a Python error involving NoneType if it isn't. To minimize
backwards compatibility issues, I am only raising the error when
g.process() is acutally called.
- the error message for custom_target with a nonexisting program
erroneously mention a not-found external program "nonexistingprogram".
The new error is similar to the one I am adding for generators.
Daniel Mensinger
Dylan Baker
Chun-wei Fan
Thibault Saunier
Richard Kjerstadius
Tamer Fahmy
Fernando Ramos
Jussi Pakkanen
Konstantin
Vladimír Čunát
TheQwertiest
makise-homura
Nirbheek Chauhan
Paolo Bonzini
Anton Kochkov