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.
This most likely happens when the source archive has files which take
advantage of case sensitivity, and someone is unfortunate enough to have
to work with broken operating systems that do not have the capacity to
use modern technology, like the 1970s invention of case sensitive
filesystems.
For example, Windows and macOS both have retrocomputing environments,
where case sensitive abilities were carefully removed from modern
filesystems in order to share the delights of classical computing with
the masses.
On such systems, innocent tarballs fail to extract with:
```
OSError: [Errno 22] Invalid argument: 'C:\path\to\file'
```
thereby demonstrating Microsoft's unbounded and enthusiastic love for
users (who are, universally, retrocomputing fans).
n.b. there is, begrudgingly, a secret option for crazy people who hate
retrocomputing to enable modern 1970s computing on Windows systems.
Naturally, no one with any sense would ever use this, and it is rightly
left in its sensible default in for example Github Actions.
Fixes#12344
lcov 2.0 deprecates `--rc lcov_branch_coverage=1` for `--rc branch_coverage=1` and
gives an error when an exclude is used on a non existing directory.
I added a version check for lcov and removed the subprojects directory from the
exclusion list if it does not exist.
Fixes#11995
Since the previous commit allows for more scenarios with name
collisions, it makes sense to expand the compile command so that it can
also take into account suffixes. i.e. meson compile -C build foo.exe can
now work if the executable has an exe suffix along with being named foo.
Dylan Baker