Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
At least, if you tried to use it when passing an install_dir. Because
T.Sequence is horrible and we should never use it, and the annotations
are a lie that produces bugs.
So, fix the annotations on CustomTarget to never allow this to happen
again, and also fix the function too. Move some definitions elsewhere
inline to satisfy the linter.
Fixes#11157
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
Regression test: libccpp has both C and C++ sources. The executable only
has C sources. It should still link using the C++ compiler. When using
both_libraries the static has no sources and thus no compilers,
resulting in the executable linking using the C compiler.
https://github.com/Netflix/vmaf/issues/1107
When using both_libraries(), or library() with default_library=both, we
remove all sources from args and kwargs when building the static
library, and replace them by the objects from the shared library. But
sources could also come from any InternalDependency, in which case we
currently build them twice (not efficient) and link both objects into
the static library.
It also means that when we needlessly build those source for the static
library, it miss order dependency on generated headers that we removed
from args/kwargs, which can cause build errors in the case the source
from static lib is compiled before the header in shared lib gets
generated.
This happened in GLib:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2917.
A subproject could have a sub-subproject as a git submodule, or part of
the subproject's release tarball, and still have a wrap file for it
(e.g. needed for [provide] section). In that case we need to use the
source tree for the sub-subproject inplace instead of downloading a new
copy into the main project.
This is the case with GLib 2.74, it has a subproject "gvdb" as git
submodule, and part of release tarball, it ships gvdb.wrap file as well.
This is generally a bad idea, e.g. it causes OSError on freebsd.
It also gets ignored by solaris and thus causes unittest failures.
The proper solution is to simply reject any attempt to set this, and log a
warning.
The install_emptydir function does apply the mode as well, and since it
is a directory it actually does something. This is the only place where
we don't reset the mode.
Although install_subdir also installs directories, and in theory it
could set the mode as well, that would be a new feature. Also it doesn't
provide much granularity and has mixed semantics with files. Better to
let people use install_emptydir + install_subdir.
Fixes#5902
Compiled languages are Meson's bread and butter, but hardly required.
This is convenient, because many test caases specifically, do not care
about testing the compiler interactions.
In such cases, we can skip doing compiler lookups which aren't used, as
they only slow down test setup.
`configure_file` is both an extremely complicated implementation, and
a strange place for copying. It's a bit of a historical artifact, since
the fs module didn't yet exist. It makes more sense to move this to the
fs module and deprecate this `configure_file` version.
This new version works at build time rather than configure time, which
has the disadvantage it can't be passed to `run_command`, but with the
advantage that changes to the input don't require a full reconfigure.
install_mode can include the setuid bit, which has the special property
(mentioned in the set_mode logic for minstall itself) of needing to come
last, because it "will get wiped by chmod" (or at least chown).
In fact, it's not just chown that wipes setuid, but other changes as
well, such as the file contents. This is not an issue for install_data /
custom_target, but for compiled outputs, we run depfixer to handle
rpaths. This may or may not cause edits to the binary, depending on
whether we have a build rpath to wipe, or an install rpath to add. (We
also may run `strip`, but that external program already has its own mode
restoration logic.)
Fix this by switching the order of operations around, so that setting
the permissions happens last.
Fixes https://github.com/void-linux/void-packages/issues/38682
This was never meant to work, it's an implementation detail of using
`importlib.import_module` and that our modules used to be named
`unstable_` that this ever worked.
Thanks to `ModuleInfo`, all modules are just named `foo.py` instead of
`unstable_foo.py`, which simplifies the import method a bit. This also
allows for accurate FeatureNew/FeatureDeprecated use, as we know when
the module was added and if/when it was stabilized.
Instead of using FeatureNew/FeatureDeprecated in the module.
The goal here is to be able to handle information about modules in a
single place, instead of having to handle it separately. Each module
simply defines some metadata, and then the interpreter handles the rest.
In order to reliably link to static libraries or individual object
files, we need to take their languages into account as well. For static
libraries this is easy: we just add the static library's list of
compilers to the build target. For extracted objects, we need to only
add the ones for the objects we use.
But we did this really inefficiently -- in fact, downright terribly. We
iterated over all source files from the extracted objects, then tried to
look up a new compiler for them. Even though the extracted objects
already had a list of compilers! This broke once compilers were made
per-subproject, because while the extracted objects have a reference to
all the compilers it needs (just like static archives do, actually) we
might not actually be able to look up that compiler from scratch inside
the current subproject.
Fix this by asking the extracted objects to categorize all its own
sources and return the compilers we want.
Fixes#10579
This is undefined behaviour, and seems to have caused test failures
when backporting Meson to an older toolchain in the Steam Runtime.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have to handle this, because Windows needs to link to the implib of
the executable (???) in order to create a shared module. This is
explicitly checked for and handled in the backend, and creating a build
target with `link_with: some_exe` still works, even. But updating
declare_dependency to typed_kwargs neglected to take that into account,
so creating a convenience interface for those same arguments failed.
The unit test was racy but surprisingly never failed on CI. The reason
is we need to ensure ninja build somelib.so before running `make` into
the external project.
The `install_headers` function now has an optional argument
`preserve_path` that allows installing multi-directory
headerfile structures that live alongside sourcecode with a
single command.
For example, the headerfile structure
headers = [
'one.h',
'two.h',
'alpha/one.h',
'alpha/two.h',
'alpha/three.h'
'beta/one.h'
]
can now be passed to `install_headers(headers, subdir: 'mylib', preserve_path: true)`
and the resulting directory tree will look like
{prefix}
└── include
└── mylib
├── alpha
│ ├── one.h
│ ├── two.h
│ └── three.h
├── beta
│ └── one.h
├── one.h
└── two.h
Fixes#3371
"targetting" is verb-derived adjective, which sort-of-works here, but
makes the whole sentence awkward, because there's no verb. Let's just
use present simple.
"tried to use" implies that the attempt was not successful, i.e. that meson
ignored the feature. But that is not what happens, apart from the warning the
feature works just fine. The new message is also shorter ;)
Some projects treat meson.project_source_root() as the root of the
dependency files, because the project itself merely wraps a bunch of
datafiles. Our validation to make sure this doesn't point to another
subproject, made use of pathlib.Path's generator for all component
paths, which... did not include the path itself. So go ahead and
explicitly check that too. Add a test case to verify it while we are at
it.
Fixes https://github.com/mesonbuild/meson/pull/10103#issuecomment-1114901033
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
There are somewhat common, reasonable and legitimate use cases for a
dependency to provide data files installed to /usr which are used as
command inputs. When getting a dependency from a subproject, however,
the attempt to directly construct an input file from a subproject
results in a sandbox violation. This means not all dependencies can be
wrapped as a subproject.
One example is wayland-protocols XML files which get scanned and used to
produce C source files.
Teach Meson to recognize when a string path is the result of fetching a
dep.get_variable(), and special case this to be exempt from subproject
violations.
A requirement of this is that the file must be installed by
install_data() or install_subdir() because otherwise it is not actually
representative of what a pkg-config dependency would provide.
Dependencies in the "if_true" keyword argument do not prevent the
sources from being used; in other words, they work just like dependencies
with "disabler: false".
However, this was broken in commit ab0ffc6a2 ("modules/sourceset: Fix
remaining typing issues", 2022-02-23) which changed logic instead of
just fixing typing issues. This was likely an attempt to avoid using
"dependencies.Dependency" after the "dependencies" field was declared,
but it also broke QEMU.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Eli Schwartz
Marvin Scholz
David Robillard
Xavier Claessens
Jussi Pakkanen
Dylan Baker
Hemmo Nieminen
Simon McVittie
Paolo Bonzini
Paweł Marczewski
Florian "sp1rit"
Tristan Partin
Zbigniew Jędrzejewski-Szmek
Peter Lesslie
Kirill Isakov