In the debug logs, always log if a dependency lookup raises a
DependencyException. In the `required: false` case, this information
would otherwise disappear forever, and we would just not even log that
we tried it -- it doesn't appear in "(tried x, y and z)".
In the `required: true` case, we would re-raise the first exception if
it failed to be detected. Update the raise message with the same
information we print to the debug logs, indicating which dependency and
which method was used in the failing attempt.
functools.partial preserves information about how the method was
created, lambdas do not. Also, we just want to freeze the first argument
and forward the rest anyway.
This also lets us get rid of a mypy error that was being ignored.
A bunch of SystemDependency subclasses overrode log_tried() even though
they used the same function anyway. Delete them -- they still print
the same thing either way.
When at least one Rust target is present, we now generate a
rust-project.json file, which can be consumed by rust-analyzer. This is
placed in the build directory, and the editor must be configured to look
for this (as it is not a default search path).
In the long run collections is the right thing to use, but until we can
require 3.9.x as the minimum we cannot annotate the collections.abc
version, only the typing version. This allows correct type annotations
in users of `CompilerArgs`, as mypy (and friends) can determine that
`CompilerArgs` is ~= `T.Sequence[str]`
Gettext should search for input files relative to the (sub)project
source root, not the global source root.
This change exposes a root_subdir member in ModuleState.
When calculating the output filename for a compiled object, we sanitize
the whole input path, more or less. In cases where the input path is
very long, this can overflow the max length of an individual filename
component.
At the same time, we do want unique names so people can recognize what
these outputs actually are. Compromise:
- for filepaths with >5 components (which are a lot more likely to cause
problems, and simultanously less likely to have crucial information that
far back in the filepath)
- if an sha1 hash of the full path, replacing all *but* those last 5
components, produces a path that is *shorter* than the original path
... then use that modified path canonicalization via a hash. Due to the
use of hashes, it's unique enough to guarantee correct builds. Because
we keep the last 5 components intact, it's easy to tell what the output
file is compiled from.
Fixes building in ecosystems such as spack, where the build environment
is a very long path containing repetitions of
`__spack_path_placeholder__/` for... reasons of making the path long.
%% survived into the output since 038b31e72b. That failed to fail, at
least in the common cases, because the whole command sequence is unnecessary /
redundant - it appears to come from cmake, which executes multiple commands
within a single CustomBuild element.
In commit d326c87fe2 we added a special
holder object for cached compilation results, with some broken
attributes:
- "command", that was never set, but used to print the log
- "args", that was set to some, but not all, of the information a fresh
compilation would log, but never used
Remove the useless args attribute, call it command, and use it properly.
We compared a Visual Studio (the IDE) version, but we wanted a MSVC (the
compiler) version. This caused the option to be passed for a few too
many versions of MSVC, and emit a "D9002 : ignoring unknown option" on
those systems.
Compare the correct version using the version mapping from
https://walbourn.github.io/vs-2017-15-7-update/Fixes#10787
Co-authored-by: CorrodedCoder <38778644+CorrodedCoder@users.noreply.github.com>
When we do wrap resolution, we do a case-insensitive lookup because
keys, i.e. `dep_name = variable_name`, are case insensitive. In order to
check whether we should process a subproject, we need to know if the
lowercased dependency name matches.
We do this by looking up the lowercase name, and assuming that the
stored name is also lowercase. But for dependency_names, this isn't "case
insensitive and stored in lowercase" so we need to manually force it to
be consistent.
Likewise, when looking up the wrap name (which works like
dependency_names and doesn't need a provide section at all) the disk
filename of the wrap file is case sensitive, but needs to be manually
forced for consistency.
wayland-scanner can generate header files that only include
wayland-client-core.h using a flag.
Add a core_only option to scan_xml to support this use case.
To differentiate it from the function parameter itself. Annotating a
function as
```
def func_foo(kwargs: kwargs.FooKwargs):
```
is confusing, both visually and to static linters.
When the build definition has changed since the last ninja invocation meson
test operated on an outdated list of tests and their dependencies. That could
lead to some tests not being run / not all dependencies being built. This was
particularly confusing because the user would see the output of
reconfiguration and rebuilding, and the next mtest invocation would have the
updated configuration.
One issue with this is that that we will now output more useless ninja output
when nothing needs to be done (the "Entering directory" part is not repeated,
as we happen to be in the build directory already). It likely is worth
removing that output, perhaps by testing if anything needs to be done with
ninja -n, but that seems better addressed separately.
Fixes: #9852
A later commit will add a second invocation of ninja, no point in having the
detection code twice.
This changes the exit code in case ninja isn't found from 125 to 127, which
seems more appropriate given the justification for returning 125 (to make git
bisect run skip that commit). If we can't find ninja we'll not succeed in
other commits either.
A subsequent commit will do a bit more during test data loading, making a
dedicated function seem advisable.
The diff looks a bit odd, using git show --diff-algorithm=patience
will make it clearer.
Currently a cosmetic bug is present: once a build dir was regenerated,
meson would start showing:
User defined options
backend: ninja
This is not true as user have not defined the option, it is default.
Fix this by omitting the `--backend ninja` parameter from "regenerate"
In my tests this does not affect the situation when one specifies
`--backend ninja` explicitly, it still shows the backend as user-defined
after reconfiguration.
Fixes: https://github.com/mesonbuild/meson/issues/10632
Meson internally knows about many languages and tools, and *FLAGS
variables, and which languages to use them for. Instead of duplicating
this logic, import it from mesonbuild.*
This logic was originally standalone, but now that it is merged into the
Meson tree we can have a single source of truth.
This can be triggered if someone tries to call a non-ID. The example
reproducer was:
```
if (var = dependency(...)).found()
```
This produced a traceback ending in
```
raise InvalidArguments(f'Variable "{object_name}" is not callable.')
UnboundLocalError: local variable 'object_name' referenced before assignment
```
After this commit, the error is reported as:
```
ERROR: AssignmentNode is not callable.
```
We use `__future__.annotations` to good effect everywhere we can, and
one of the effects of this is that annotations are automatically
stringized and don't need to be evaluated, using less memory and
computation. But this only affects actual annotations -- a cast is just
a function with an argument, so the compiler has no idea that it's an
annotation to be stringized.
Do this manually.
This is supposed to expose all primitives together, but to do that we
need to actually "use" each variable in `__all__`, which we... didn't.
Sorry about that.
Strictly speaking code restructuring isn't needed, but making this PEP8
compliant results in indentation of the code that reduces the
readability. By moving the offending code on the outside of the method
call, the readability is maintained.
What happens is this:
- liba is a convenience static library
- libb is an installed static library
- libb links in liba with --link-whole
- libc links to libb
- we generate a link line with libb *and* liba, even though libb is a
strict superset of liba
This is a bug that has existed since the we stopped using link-whole to
combine convenience libraries, and to instead propagate their
dependencies up. For most linkers this is harmless, if inefficient.
However, for apple's ld64 with the addition calling `ranlib -c`, this
ends up causing multiple copies of symbols to clash (I think that other
linkers recognize that these symbols are the same and combine them), and
linking to fail.
The fix is to stop adding libraries to a target's `link_whole_targets`
when we take its objects instead. This is an all around win since it
fixes this bug, shortens linker command lines, and avoids opening
archives that no new symbols will be found in anyway.
Xavier Claessens
Yang Bo
Eli Schwartz
Dylan Baker
David Ward
Andres Freund
Volker Weißmann
Rosen Penev
Mark Bolhuis
Thomas Li
Konstantin Kharlamov
Jehan
aleksander
Samay Sharma
Alf Henrik Sauge
Fabian Orccon