| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Since commit 44ce04537 ("cargo: Add library API version into its name", 2025-10-28),
the target names provided by cargo subprojects have a suffix corresponding to the
library API; for example, the target that used to be "gtk4" is now "gtk4+0_10".
This however is an implementation detail, and the change broke rust_dependency_maps
that expected to use the crate name.
While the target name is preferrable, and will work great when Meson is able
to create dependency maps by itself (as is the case for the Cargo interpreter),
preserve the old behavior by checking also the entry corresponding to the result
of _get_rust_crate_name.
Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Give a practical example of how it is used.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Place the build products in a directory of the specified name
somewhere within the build directory. This allows use of the target
that includes a specific directory name:
#include <subdir/configure.h>
This also allows creating targets with the same basename by using
different subdirectory names.
v2:
Move build_subdir to Target class.
Error if path separator in build_dir
v3:
Rename to 'build_subdir' to make it clear that the name is
appended to a meson-specific build directory, and does not
provide the user with a way to define the overall meson build
hierarchy.
Allow build_subdir to include path separators.
Support 'build_subdir' for configure_file.
build_subdir must not exist in the source directory and
must not contain '..'
Add documentation and tests
v4:
Rebase and prepare for version 1.9.1
Add failing test case when build_subdir is present in the
project.
Add release note snippet
v5:
Clarify wording on restrictions on the value of build_subdir. Use
the same wording in each place this restriction is described.
v6:
Move path validation to shared function, validate_build_subdir,
instead of duplicating the tests in two places.
v7:
Update version numbers to 1.10.0
Add TypedDict updates.
Remove spurious build_subdir instance variable
v8:
Oops, missed one version number update.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Defining public API in a cross platform library is painful, especially
on Windows. Since every library have to define pretty much the same
macros, better do it in Meson.
|
|
|
|
Which have existed for a *long* time, but are only documented in the
Vala docs.
|
|
When arrays were added they were called arrays. Because the are
implemented with Python lists, that language started leaking into
talking about Meson types. This is confusing. I've attempted, as much as
possible, to move to using one name, array. I picked array because 1)
It's the original name used, and 2) what Meson has are more properly
arrays as they have a fixed length, while a critical property of lists
are the ability to link and unlink them.
There are a couple of places where the list language has leaked into the
names of keyword arguments. I have not made any attempt to change those,
I don't know if it's that useful or not.
|
|
This commit harmonizes the handling of `d_import_dirs` and
`include_directories`. The treatment of `d_import_dirs` was also
different depending on the context: in `declare_dependency` it was
treated like the `include_directories`, but in `build_target` et al,
it had special treatment. With this commit, they are all treated
by the same function. The documentation has been updated to
reflect this.
Fixes #12742
|
|
Way back in Meson 0.25, support was added to `vala_args` for Files.
Strangely, this was never added to any other language, though it's been
discussed before. For type safety, it makes more sense to handle this in
the interpreter level, and pass only strings into the build IR.
This is accomplished by adding a `depend_files` field to the
`BuildTarget` class (which is not exposed to the user), and adding the
depend files into that field, while converting the arguments to relative
string paths. This ensures both the proper build dependencies happen, as
well as that the arguments are always strings.
|
|
Meson already knows if it's a shared or static library, user only need
to specify the ABI (Rust or C).
|
|
the use of /LINKWHOLE with MSVC and the behaviour of re-exporting symbols of individual objects in a static library.
|
|
|
|
|
|
This allows changing the crate name with which a library ends up being
available inside the Rust code, similar to cargo's dependency renaming
feature or `extern crate foo as bar` inside Rust code.
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The documentation for build_target(...) does not list file or str as
the possible types for the "objects" keyword argument, even though in
theory the argument is meant for prebuild object files that are part
of the sources.
Of course that is only the theory, because an ExtractedObjects object
is probably used a lot more than a file in the source tree. But
at least make the reference manual's typing information accurate.
|
|
This is based on searching for `@FeatureNew*` decorators.
There is also one correction to a version in a decorators;
`build_by_default` was added in #1303, which is 0.38.0, not 0.40.0.
|
|
|
|
Dlang uses both integer version "levels" and arbitrary string
identifiers, and we support both, but don't mention it in the docs.
Also update a test case to pass one via declare_dependency. We already
test this kwarg for build_target.
|
|
In the original RefMan 2.0 implementation, the types for this were
filled in as `str | file`, but the code only ever accepted the former.
Fix the documentation so that it aligns with reality.
Fixes #10338
|
|
Structured Sources
|
|
|
|
|
|
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
<https://github.com/mesonbuild/meson/commit/00f5dadd5b7d71c30bd7393d165a87f554eb92e5>.
Fixes: https://github.com/mesonbuild/meson/issues/2561
|
|
|
|
|
