Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
In various situations we want to figure out what type of compiler we
have, because we want to know stuff like "is it the pgi one", or "does
it use msvc style". The compiler object has this property already, via
an API specifically designed to communicate this info, but instead we
performed isinstance checks on a compiler class.
This is confusing and indirect, and has the side effect of requiring
more imports everywhere. We should do away with it.
When at least one Rust target is present, we now generate a
rust-project.json file, which can be consumed by rust-analyzer. This is
placed in the build directory, and the editor must be configured to look
for this (as it is not a default search path).
Currently a cosmetic bug is present: once a build dir was regenerated,
meson would start showing:
User defined options
backend: ninja
This is not true as user have not defined the option, it is default.
Fix this by omitting the `--backend ninja` parameter from "regenerate"
In my tests this does not affect the situation when one specifies
`--backend ninja` explicitly, it still shows the backend as user-defined
after reconfiguration.
Fixes: https://github.com/mesonbuild/meson/issues/10632
Apple's AR is old, and doesn't add externed symbols to the symbol table,
instead relying on the user calling ranlib with -c. We need to do that
for the user
In commit 4ca9a16288 we added unreliable
support (it warns you if you try it) for gcc-compatible treatment of
uppercase-C files being C++ instead of C. In order to handle it
correctly, we needed to evaluate can-compile by special-casing "C" to
avoid lowercasing it for comparisons.
This didn't cover all cases where we check if "C" is a C++ language
file. We also straight-up check the language of a file (rather than
working backwards to see if a C++ compiler can compile it) when doing
module scanning, and this needs to special-case "C" as well.
We also had one case where we only checked lowercase fortran extensions,
but not lowercase C++ extensions. While we are at it, use lowercase for
C++ as well, except the "C" special case.
Fixes#10629
Ninja backend will fail to find the vs dep dependency
prefix string in a mingw64 environment. This change
simply updates the regex to be able to capture mingw64's unique
file separation pattern.
At several points in the code base, f-strings are not correctly expanded
due to missing 'f' string prefix. This fixes all the occurrences I could
find.
A single target could be picked for unity build, and in that case
extract_objects() should not be allowed.
Likewise for the opposite case, where extract_objects() should be allowed
if unity build is disabled for a single target. A test that covers that
case is added later.
'meson-test-prereq' now depends on any targets that were formerly added
directly to 'all'. Behavior is not changed -- the all target still
depends on this other meta-rule, and thus indirectly depends on all
targets it used to depend on.
It is now possible to build just the targets needed for the testsuite
and then e.g. run `meson test --no-rebuild`.
We don't want to allow targets that conflict with:
- our aliased meson-* targets for phony commands
- any meson-*/ directories we create for internal purposes
We do want to allow targets such as:
- our own meson-*.X manpages
There are a couple routes we could take.
Using a better restriction, such as `meson-internal__*`, is trivially
done for our aliased targets, but changing directory names is...
awkward. We probably cannot do this, and doing the former but not the
latter is not very useful.
We could also carefully allow patterns we know we won't use, such as
file extensions, but which the manpages need, which works for our
directories and for many aliased targets, but run_target() is
user-specified and can be anything.
Use a hybrid approach to cover both use cases. We will now allow target
names that fulfill *all* the following criteria:
- it begins with "meson-"
- it doesn't continue with "internal__"
- it has a file extension
Every phony target has a special indirection rule created because ninja
is bad at deleting generated outputs and tries to delete phony outputs
too.
Instead of invoking this as a separate helper post-creation function to
create the alias, wrap NinjaBuildElement and create it behind the
scenes. This simplifies target naming and means one less line at every
single use site.
Forcing serialization on when writing out the build rule makes very
little sense. It was always "forced" on because we mandated a couple of
environment variables due to legacy reasons.
Add an attribute to RunTarget to say that a given target doesn't *need*
those environment variables, and let ninja optimize them away and run
the command directly if set.
That method had nothing specific to the backend, it's purely a Target
method. This allows to cache the OptionOverrideProxy object on the
Target instance instead of creating a new one for each option lookup.
We print a warning if a compilation database isn't successfully
generated, which is good, because that gives some visibility in case the
user really wanted to use the compdb. But warnings default to being
fatal with --fatal-meson-warnings, which is not so good, because this
isn't a very important warning at all, and we'd rather not error out in
such cases when building works fine and a random bonus IDE feature
doesn't work.
Mark this particular warning as non-fatal.
Fixes side issue in https://github.com/mesonbuild/wrapdb/pull/343#issuecomment-1074545609
In the even that all of the inputs are generated, and they're all
generated into the same folder, and there are no subfolders, we would
fail to correctly handle all of the files after the main file. Let's fix
that.t
We currently don't handle subdirectories correctly in
structured_sources, which is problematic. To make this easier to handle
correctly, I've simply changed `structured_sources` to only use Files
and not strings as an implementation detail.
Android requires shared modules that use symbols from other shared
modules to be linked before they can be dlopen()ed in the correct
order. Not doing so leads to a missing symbol error:
https://github.com/android/ndk/issues/201
We need to always allow linking for this. Also add a soname, although
it's not confirmed that it's needed, and it doesn't really hurt if it
isn't needed.
For static library crates that depend on other internal static library
crates, all link_with targets get promoted to link_whole targets. Due to
a bug, only link_with targets are considered when generating a Rust
target for the ninja backend. This made it impossible to link a Rust
static library with another internal Rust static library.
This change fixes that issue by chaining link_whole_targets with
link_targets, just like many other languages within the ninja backend.
Basically the last thing we did during target processing was to generate
shlib symlinks for e.g. libfoo.so -> libfoo.so.1.
In some cases we would dispatch to another function and return early,
though, which meant we never got far enough to generate the symlinks.
This then led to breakage when people tried to compile against libfoo.so
This surely breaks -uninstalled.pc usage, and also caused problems in
https://github.com/rust-lang/rust/pull/90260
When a custom_target() uses an env, meson uses a wrapper
script to run the executable. This breaks the console: kwarg
because the wrapper script buffers the output. Fix it by setting
the verbose flag which will not buffer output.
Emit a detailed deprecation warning that explains what to do instead.
Also add a unittest.
```
DEPRECATION: target prog links against shared module mymod, which is incorrect.
This will be an error in the future, so please use shared_library() for mymod instead.
If shared_module() was used for mymod because it has references to undefined symbols,
use shared_libary() with `override_options: ['b_lundef=false']` instead.
```
Fixes https://github.com/mesonbuild/meson/issues/9492
We say:
> If version 4.2 or higher of the first is found, targets coverage-text,
> coverage-xml, coverage-sonarqube and coverage-html are generated.
But this is totally untrue. Make it true, by actually checking (and
not generating broken coverage commands when older versions of gcovr are
found).
Fixes#9505
Since they will never be used outside of the build directory, they do
not need to literally contain the .o files, and references will be
sufficient.
This covers a major use of object libraries, which is that the static
library would potentially take up a lot of space by including another
copy of every .o file.
Fixes#9292Fixes#8057Fixes#2129