Regression in commit a3d287c553.
When a given kwarg is not specified, we want to not generate it as a
simd variant. Since the default for buildtarget sources is `[]` it
resulted in building a static library with no sources, and a warning
stating that this was buggy and will eventually be removed.
Fix this by teaching buildtarget sources to allow None, and defaulting
to it specifically for the simd module. We can check this and then skip
processing entirely.
Fixes#12438
adb1a360b9 added the feature and also the
usual meson-style warning to users that might be using the feature but
were not targeting a new enough meson version. Well unfortunately the
warning both doesn't actually work (it didn't take different directories
into account) and is also really slow because it creates an O(N^2) loop
for checking this.
Instead, rework this by adding an additional set that stores a tuple
containing the target name and its subdirectory. We only add this tuple
if the target is an executable since it is the only time it will be
relevant. After that, simply check if the name + subdir combination
already exists in the set along with the target being executable. If so,
then we execute FeatureNew which may possibly warn. This is a simply
O(1) lookup which is way faster. Fixes#12404.
Which allow passing arguments specifically to the static or shared
libraries.
For design, this is all handled in the interpreter, by the build layer
the arguments are combined into the existing fields. This limits changes
required in the mid and backend layers
`java_args` is only valid for `jar()` (and `build_target()`, but that's
deprecated), while all other language args are invalid for `jar()`. This
deprecates all of those arguments, that shouldn't be allowed, and
provides useful error messages. As an advantage, this avoids generating
useless `java_static_args` and `java_shared_args`.
In order to get useful error messages for both build_target and
executable + *library, we need to separate LIBRARY and BUILD_TARGET a
bit.
This also moves the repacking into the interpreter, making the build
implementation simpler and removing a layering violation. This also
makes use a defaultdict to remove the need to call `.get()`
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.
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
This differentiates export_dynamic being explicitly set to False from it
being unset. This allows us to deprecate explicitly setting
export_dynamic to false, but setting implib. This is already the case in
the other direction, if implib is False but export_dynamic is enabled
then we get a hard error.
This also moves the validation up to the Interpreter and out of the
build level.
In commit dd22546bdd the various
typed_pos_args for different BuildTarget functions was refactored into a
common tuple of types.
It overlooked the fact that jar specifically does NOT accept the same
types, and began to allow passing structured_sources in.
The method can be overridden by setting the `method` key in the wrap
file and always defaults to 'meson'. cmake.subproject() is still needed
in case specific cmake options need to be passed.
This also makes it easier to extend to other methods in the future e.g.
cargo.
Rustc does not produce object files we can reuse to build both
libraries. Ideally this should be done with a single target that has
both `--crate-type` arguments instead of having 2 different build rules.
As temporary workaround, build twice and ensure they don't get conflicts
in intermediary files created by rustc by passing target's private
directory as --out-dir.
See https://github.com/rust-lang/rust/issues/111083.
Eli Schwartz
Dudemanguy
Dylan Baker
Xavier Claessens
Nomura