Installing python sources causes the python module to call
create_install_data() before Ninja backends adds extra outputs to Vala
targets.
Target objects are supposed to be immutable, adding outputs that late is
totally wrong. Add extra vala outputs immediately, but be careful
because the main output is only added later in post_init(). Luckily
the base class already puts a placeholder item in self.outputs for the
main filename so we can just replace self.outputs[0] instead of
replacing the whole list which would contain vala outputs at that stage.
This is surprisingly what SharedLibrary was already doing.
Coredata is where all option handling is done so it makes sense there.
It is a view on a list of options for a given subproject and with
optional overrides. This change prepare for using that view in a more
generic way in the future.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
When an installed static library A links to an internal static library B
built using a custom_target(), raise an error instead of a warning. This
is because to be usable, A needs to contain B which would require to
extract the archive to get its objects files.
This used to work, but was printing a warning and was installing a
broken static library, because we used to overlink in many cases, and
that got fixed in Meson 1.2.0. It now fails at link time with symbols
from the custom target not being defined. It's better to turn the
warning into a hard error at configure time.
While at it, noticed this situation can happen for any internal custom
or rust target we link to, recursively.
get_internal_static_libraries_recurse() could be called on CustomTarget
objects which do not implement it, and even if we did not call that
method, it would still fail when trying to call extract_all_objects() on
it.
Fixes: #12006
Improve the error message when a build target is assigned as dependency
of another build target, which allows to better pinpoint where the issue
lies on.
In the example that follow, modules/meson.build:294 is in a for loop
creating library targets from an array of dictionary, and doesn't point
to the location where interop_sw_plugin is assigned with vlc_opengl:
Before:
modules/meson.build:294:17: ERROR: Tried to use a build target as a dependency.
You probably should put it in link_with instead.
After:
modules/meson.build:294:17: ERROR: Tried to use a build target vlc_opengl as a dependency of target interop_sw_plugin.
You probably should put it in link_with instead.
It would probably be best to directly pinpoint where the assignment was
made but it's probably harder so start simple by saying what is
concerned by the error.
We allow custom_target() but check for it based on hasattr, ever since
the initial implementation way back in the day, in commit
66a6ea984b. This is a bit broken because
various objects might support that but still aren't supposed to work. We
can actually just use isintance checks like we do immediately above,
which are more accurate and avoid crashes on things that aren't even
targets at all, like run_target(). Although custom_target indexes are
actually targets those didn't work either.
Fixes#9648
Since it's deprecated anyway, we don't really want to plumb it all the
way down into the build and backend layers. Instead, we can just turn
it into a `win_subsystem` value in the interpreter if `win_subsystem`
isn't already set.
This would be either the value `kwargs['install']`, or `False`. There
isn't any case that `BuildTarget.need_install` handles that
`BuildTarget.install` doesn't handle, if we just initialized it
correctly. So, just set Target.install correctly in the super
initializer, and do away with need_install.
Also move it into the Jar class. This is an exclusive Jar keyword
argument, and is only used inside java paths, so there's no reason to
have this in all build targets.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
This fixes regression caused by
3162b901ca
that changes the order in which libraries are put on the link command.
In addition, that commit was wrong because libraries from dependencies
were processed before process_compiler() is called, which that commit
wanted to avoid.
We need a union of the compilers used by the target, and by those used
by all dependencies, not all the compilers in all projects. We do,
however, need to look compilers up from all possible compilers, as a
dependency that is a subproject could use a language not present in the
current project.
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
To take good decisions we'll need to know if we are a Rust library which
is only know after processing source files and compilers.
Note that is it not the final list of compilers, some can be added in
process_compilers_late(), but those are compilers for which we don't
have source files any way.
Case 1:
- Prog links to static lib A
- A link_whole to static lib B
- B link to static lib C
- Prog dependencies should be A and C but not B which is already
included in A.
Case 2:
- Same as case 1, but with A being installed.
- To be useful, A must also include all objects from C that is not
installed.
- Prog only need to link on A.
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.
The library names are directly mapped to filenames by meson while the
crate name gets spaces/dashes replaced by underscores. This works fine
to a certain degree except that rustc expects a certain filename scheme
for rlibs that matches the crate name.
When using such a library as a dependency of a dependency compilation
will fail with a confusing error message.
See https://github.com/rust-lang/rust/issues/110460
Dylan Baker