Automatically generate additional variables and write them into the
generated pkg-config file.
This means projects no longer need to manually define the ones they
use, which is annoying for dataonly usages (it used to forbid setting
the base library-relevant "reserved" ones, and now allows it only for
dataonly. But it's bloat to manualy list them anyway).
It also fixes a regression in commit
248e6cf473 which caused libdir to not be
set, and to be unsettable, if the pkg-config file has no libraries but
uses the ${libdir} expansion in a custom variable. This could be
considered likely a case for dataonly, but it's not guaranteed.
This bring us in line with Autotools and CMake and it is useful
for platforms like Nix, which install projects
into multiple independent prefixes.
As a consequence, `get_option` might return absolute paths for some
directory options, if a directory outside of prefix is passed.
This is technically a backwards incompatible change but its effect
should be minimal, thanks to widespread use of `join_paths`/`/` operator
and pkg-config generator module. It should only cause an issue when
a path were constructed by concatenating the value of directory path option.
Also remove a comment about commonpath since we do not use that since
<00f5dadd5b>.
Fixes: https://github.com/mesonbuild/meson/issues/2561
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.
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
This was allows up to 0.61.0 (including with the initial type
annotations), but was accidentally broken by fixes for other bugs in
0.61.1.
Fixes: #9883
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
check: true is needed for an actual regression test, but that requires
a pedantically correct gtk-doc configuration, which I attempted to do
and failed. So let's just put check: false so we get *some* coverage:
just that typed_kwargs accepts the argument.
Related to https://github.com/mesonbuild/meson/pull/9807
Fixes a bug where the subproject version was not validated
when the subproject had already been processed.
The bug would cause inconsistent build results if the subproject was
referenced more than once (diamond) with conflicting version requirements.
pkgconf has a bug on MSYS2 due to which prefixes with spaces are not
handled correctly if the library has a Requires: on another library
and both have prefixes with spaces in them.
See: https://github.com/pkgconf/pkgconf/issues/238
So move the unit test to libanswer.pc instead of libfoo.pc till that
is fixed.
If a pkg-config dependency has multiple libraries in it, which is the
most common case when it has a Requires: directive, or when it has
multiple -l args in Libs: (rare), then we don't add -Wl,-rpath
directives to it when linking.
The existing test wasn't catching it because it was linking to
a pkgconfig file with a single library in it. Update the test to
demonstrate this.
This function was originally added for shared libraries in the source
directory, which explains the name:
https://github.com/mesonbuild/meson/pull/2397
However, since now it is also used for linking to *all* non-system
shared libraries that we link to with absolute paths:
https://github.com/mesonbuild/meson/pull/3092
But that PR is incomplete / wrong, because only adding RPATHs for
dependencies that specify a single library, which is simply
inconsistent. Things will work for some dependencies and not work for
others, with no logical reason for it.
We should add RPATHs for *all* libraries. There are no special length
limits for RPATHs that I can find.
For ELF, DT_RPATH or DT_RUNPATH are used, which are just stored in
a string table (DT_STRTAB). The maximum length is only a problem when
editing pre-existing tags.
For Mach-O, each RPATH is stored in a separate LC_RPATH entry so there
are no length issues there either.
Fixes https://github.com/mesonbuild/meson/issues/9543
Fixes https://github.com/mesonbuild/meson/issues/4372
When generating pkgconfig file for a library that links to an
uninstalled static library built by custom_target() Meson was crashing
when trying to access some attributes that does not exist on that class.
Also fix is_internal() implementation, it only really make sense on a
CustomTargetIndex or if CustomTarget has only a single output.
Add ability to mutate a target's `extra_files` list through the
rewriter.
The logic is copied from sources add/rm, but changes the `extra_files`
kwarg instead of the sources positional argument.
Has additional logic to handle creating the `extra_files` list if it
doesn't exist.
Use a proper install option for this. Now `install_<type>` can directly
override `install` instead of passing a boolean to the string kwarg
`install_dir_<type>`.
generate_gir forces building both the typelib and gir, and some people
only want one or the other (probably only the typelib?) which means
flagging the other as install_dir: false in the same way custom_target
supports.
As this always worked, albeit undocumented, make sure it keeps working.
It's pretty reasonable to allow, anyway.
Fixes https://github.com/mesonbuild/meson/pull/9484#issuecomment-980131791
Meson was passing only the first output and warning about it. To do this
easily, refactor construct_target_rel_path to return a list.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes https://github.com/mesonbuild/meson/issues/9492
Make the handling of bindgen inputs consistent with the inputs and outputs of
source_strings_to_files.
However, for the first source argument reject anything that cannot
possibly be an header file. This also fixes a mypy failure from the next
patch, since ExtractedObjects does not have a zero-argument get_outputs
method.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Currently, if you pass a `[]string`, but the argument expects
`[]number`, then you get a message like `expected list[str] but got
list`. That isn't helpful. With this patch arrays and dictionaries will
both print messages with the types provided.
This is only relevant on certain versions of meson, so do not print it
when meson_version is too low.
The message itself is not precisely a deprecation warning, since
ostensibly it may be an unlikely coding mistake. It is probably an
attempt to implement `copy: true`, but it might not be, hence "warning"
instead of "deprecation". So although we could switch this to a
FeatureDeprecated, that is not being done at this time.
This tries to link the system provided python, which is deprecated and
will result in an ambiguous error like "your binary is not an allowed
client of .../Library/Frameworks/python.framework/python.tbd for
architecture x86_64".
Without this patch, the name of the RunTarget is passed to the
install script; for the enclosed test, meson setup (incorrectly)
succeeds, but installation fails.
Fixes the following error in the testcase:
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/ninjabackend.py", line 548, in generate
self.generate_tests()
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/ninjabackend.py", line 1093, in generate_tests
self.serialize_tests()
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 567, in serialize_tests
self.write_test_file(datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 943, in write_test_file
self.write_test_serialisation(self.build.get_tests(), datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1017, in write_test_serialisation
pickle.dump(self.create_test_serialisation(tests), datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1002, in create_test_serialisation
cmd_args.append(self.construct_target_rel_path(a, t.workdir))
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1021, in construct_target_rel_path
return self.get_target_filename(a)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 253, in get_target_filename
assert(isinstance(t, build.BuildTarget))
Eli Schwartz
Alyssa Ross
Jan Tojnar
Tobias Pankrath
Daniel Mensinger
Zach Reizner
Paolo Bonzini
Xavier Claessens
Dylan Baker
Arsen Arsenović
Matthias Klumpp
Gatgat
Nirbheek Chauhan
Øyvind Aarrestad Aakre
Itoh Shimon
Jussi Pakkanen
Pablo Correa Gómez
Celeste Wouters
Benoit Pierre
Jon Turney
Dudemanguy