| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
|
|
|
|
Along the way, add __future__ annotations where lacking.
|
|
Introduced via commit 0d0a4fa0fe02ca8297743a5a8e64ee72060cc990, probably
in the course of heavy rebasing.
|
|
|
|
There are a couple issues that combine to make the current handling a
bit confusing.
- we call it "install_dir_name" but it is only ever the class default
- CustomTarget always has it set to None, and then we check if it is
None then create a different variable with a safe fallback. The if is
useless -- it cannot fail, but if it did we'd get an undefined
variable error when we tried to use `dir_name`
Remove the special handling for CustomTarget. Instead, just always
accept None as a possible value of outdir_name when constructing install
data, and, if it is None, fall back to {prefix}/outdir regardless of
what type it used to be.
|
|
|
|
and fix a bug in the backend that the correct annotations uncover
|
|
Since they are actually dependencies out the output not the Generator
itself.
This fixes dependency issues in the ninja backend, allowing Meson to
rebuild more accurately. It also does sometimes in the vs backend, but
there are problems in the vs backend I'm not sure how to solve. The
vsbackend is, itself, so fragile looking I don't want to get too
involved with it.
|
|
This doesn't actually fix the problem, but it provides parity with what
is currently happening. I don't have access to a Windows machine to
further debug, however, so not breaking anything is the best I can do
ATM.
|
|
|
|
|
|
|
|
They're not used outside of the gnome module anyway, and they create
some annoying potentials for dependency loops
|
|
We don't want to allow targets that conflict with:
- our aliased meson-* targets for phony commands
- any meson-*/ directories we create for internal purposes
We do want to allow targets such as:
- our own meson-*.X manpages
There are a couple routes we could take.
Using a better restriction, such as `meson-internal__*`, is trivially
done for our aliased targets, but changing directory names is...
awkward. We probably cannot do this, and doing the former but not the
latter is not very useful.
We could also carefully allow patterns we know we won't use, such as
file extensions, but which the manpages need, which works for our
directories and for many aliased targets, but run_target() is
user-specified and can be anything.
Use a hybrid approach to cover both use cases. We will now allow target
names that fulfill *all* the following criteria:
- it begins with "meson-"
- it doesn't continue with "internal__"
- it has a file extension
|
|
Every phony target has a special indirection rule created because ninja
is bad at deleting generated outputs and tries to delete phony outputs
too.
Instead of invoking this as a separate helper post-creation function to
create the alias, wrap NinjaBuildElement and create it behind the
scenes. This simplifies target naming and means one less line at every
single use site.
|
|
Previously the output of the custom target was always captured
and it was not possible to see the output unless build failed.
|
|
|
|
Further work pending GCC bug #105467 and/or Ninja bug #1962.
|
|
|
|
Forcing serialization on when writing out the build rule makes very
little sense. It was always "forced" on because we mandated a couple of
environment variables due to legacy reasons.
Add an attribute to RunTarget to say that a given target doesn't *need*
those environment variables, and let ninja optimize them away and run
the command directly if set.
|
|
|
|
|
|
|
|
|
|
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
|
|
cython_args was previoously ignored by Meson.
|
|
We print a warning if a compilation database isn't successfully
generated, which is good, because that gives some visibility in case the
user really wanted to use the compdb. But warnings default to being
fatal with --fatal-meson-warnings, which is not so good, because this
isn't a very important warning at all, and we'd rather not error out in
such cases when building works fine and a random bonus IDE feature
doesn't work.
Mark this particular warning as non-fatal.
Fixes side issue in https://github.com/mesonbuild/wrapdb/pull/343#issuecomment-1074545609
|
|
|
|
Since OptionKey is used we can mix all options together in a single
dictionary. That's already what we do in coredata.options.
|
|
Previously Meson lacked the ability to add resources to jar files.
Fixes #9945
|
|
In the even that all of the inputs are generated, and they're all
generated into the same folder, and there are no subfolders, we would
fail to correctly handle all of the files after the main file. Let's fix
that.t
|
|
We currently don't handle subdirectories correctly in
structured_sources, which is problematic. To make this easier to handle
correctly, I've simply changed `structured_sources` to only use Files
and not strings as an implementation detail.
|
|
In this case, the test fname might have an implicit extension and cannot
be found by `os.path.isfile()`.
We cannot use `shutil.which()` to handle platform differences, because
not all test fnames are executable -- for example Java jars.
The test representation does have an "is built" attribute which in
theory should work here, because all built targets definitely have their
full filename known to Meson, but it turns out to be misnamed. Rename it
correctly and add an actual "is built" attribute to check.
Tests which aren't built by Meson can be assumed to exist without
consulting their existence on the filesystem.
Fixes #10027
|
|
Structured Sources
|
|
|
|
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
|
|
|
|
|
|
Versioned shared libraries should have .so file in devel, .so.1 and
.so.1.2.3 in runtime.
Fixes: #9811
|
|
|
|
It is created twice for ninja and for introspection.
|
|
|
|
|
|
Android requires shared modules that use symbols from other shared
modules to be linked before they can be dlopen()ed in the correct
order. Not doing so leads to a missing symbol error:
https://github.com/android/ndk/issues/201
We need to always allow linking for this. Also add a soname, although
it's not confirmed that it's needed, and it doesn't really hurt if it
isn't needed.
|
|
This substitution matches the behaviour of rustc[1] when inferring
crate name based on file name.
[1]: https://github.com/rust-lang/rust/tree/4e8fb743ccbec27344b2dd42de7057f41d4ebfdd/compiler/rustc_session/src/output.rs#L88
|
|
New keyword argument `verbose` for tests and benchmarks
|
|
For static library crates that depend on other internal static library
crates, all link_with targets get promoted to link_whole targets. Due to
a bug, only link_with targets are considered when generating a Rust
target for the ninja backend. This made it impossible to link a Rust
static library with another internal Rust static library.
This change fixes that issue by chaining link_whole_targets with
link_targets, just like many other languages within the ninja backend.
|
|
This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes #9721
|
|
Add a new keyword argument to test() and benchmark(), completing the
implementation of the feature.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
