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).
* 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.
If the detected gpgme version is recent enough to match the version in
which upstream pkg-config files were added, assert that the default
found dependency is of the pkgconfig type.
Since gpgme 1.13.0, pkg-config files are available and this is the
preferred way to detect the dependency. Without this, projects that wish
to generate pkg-config files that Requires.private on gpgme, now have
their custom dependency() fallbacks overridden with an incorrect
configtool dependency.
As a newcomer to the Meson build system, I found the documentation of the `library()` function to be a bit misleading. Eventually I found what 'user option' referred to after digging through the docs.
This just adds a link back to the page that describes the options that are referred to in this paragraph.
When using clang as an objc/objc++ compiler, identify if it's a Windows
targeted compiler, so that GnuLikeCompiler::get_pic_args() doesn't use
'-fPIC', which clang considers an error for the Window target.
Future work: Factor out parsing the clang target string from the
detectors for various languages.
Now we have some information in CI logs about what compiler is actually
being used, fix some places where an unexpected compiler is being picked
up.
Avoid picking up gcc-objc and gfortran from PATH in vs2017 image for VS
test runs.
Use clang for objc/objc++ in MSYS2 clang test runs, rather than picking
up gcc from path.
Also install gfortran for fortran tests on Cygwin.
Daniel Mensinger
Dylan Baker
Tamer Fahmy
Fernando Ramos
Jussi Pakkanen
Jon Turney
Konstantin
Vladimír Čunát
TheQwertiest
makise-homura
Nirbheek Chauhan
Paolo Bonzini
Anton Kochkov
Eli Schwartz
Keefer Rourke