The DCompiler and DmDLikeCompiler classes both implement the exact same
`get_feature_args()` method. The DmdLikeCompiler inherits the DCompiler.
As such, removing it doesn't change the behavior of anything, but
decreases the chances of bugs being introduced, as well as LoC.
The <lang>_stdlib can be used in cross files to use a custom standard library
for a given language.
When cpp_stdlib is used in a cross file, meson passes
* -nostdinc++ to the compiler
* -nostlib to the linker
According to [1] (gcc) and [2] (clang), we should pass -nostlib++ to the linker
when we don't want to link to the standard C++ library.
Currently, we pass -nostlib.
Fix this by implementing a C++ specific get_no_stdlib_link_args() function.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-nostdlib_002b_002b
[2] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-nostdlib
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
The MSVC linker errors out if a line in the rspfile is too long.
The resolution is to use the built-in ninja keyword $in_newline instead of $in, which splits each input into separate lines.
A rebase of the current branch is the wrong thing to do if the
revision (branch) specified in the wrap changed, which is the case in
the majority of cases, such as when switching from one release branch
to another.
Don't leave the subproject tree in a broken / conflicting state. The
user is most likely not a git expert who will know what magic command
to run to fix their source tree.
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.