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.
Since we scan all dependencies for build-only RPATHs now (which are
removed on install), we must take care not to add build-only RPATHs
pointing to directories that dependencies explicitly add -Wl,-rpath
link args for, otherwise the paths will get wiped on install.
Caught by LinuxlikeTests::test_usage_pkgconfig_prefixes
If a pkg-config dependency has multiple libraries in it, which is the
most common case when it has a Requires: directive, or when it has
multiple -l args in Libs: (rare), then we don't add -Wl,-rpath
directives to it when linking.
The existing test wasn't catching it because it was linking to
a pkgconfig file with a single library in it. Update the test to
demonstrate this.
This function was originally added for shared libraries in the source
directory, which explains the name:
https://github.com/mesonbuild/meson/pull/2397
However, since now it is also used for linking to *all* non-system
shared libraries that we link to with absolute paths:
https://github.com/mesonbuild/meson/pull/3092
But that PR is incomplete / wrong, because only adding RPATHs for
dependencies that specify a single library, which is simply
inconsistent. Things will work for some dependencies and not work for
others, with no logical reason for it.
We should add RPATHs for *all* libraries. There are no special length
limits for RPATHs that I can find.
For ELF, DT_RPATH or DT_RUNPATH are used, which are just stored in
a string table (DT_STRTAB). The maximum length is only a problem when
editing pre-existing tags.
For Mach-O, each RPATH is stored in a separate LC_RPATH entry so there
are no length issues there either.
Fixes https://github.com/mesonbuild/meson/issues/9543
Fixes https://github.com/mesonbuild/meson/issues/4372
Meson was passing only the first output and warning about it. To do this
easily, refactor construct_target_rel_path to return a list.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For libraries installed to libdir, it's not expected to have rpath
hooked up. But for non-default libdirs, the path might not get searched
by default. `ldconfig -m <libdir>` is convenient here, as it will
programmatically add a new directory to search for shared libraries, so
the resulting installed programs work out of the box.
Include the dragonfly BSD platform name, which doesn't match the 'bsd'
catch-all pattern.
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
This previously worked because we were accidentally doing this via
mutation. However, doing this via mutation is not a good way to do it,
we should be explicit.
Fixes#9542
fixes#6314
in case of backend is vs2017 or vs2019 place LanguageStandard tag with stdcpp version and LanguageStandard_C tag with stdc version in .vcxproj file
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
This replaces the absolute hack of using
```
install_subdir('nonexisting', install_dir: 'share')
```
which requires you to make sure you don't accidentally or deliberately
have a completely different directory with the same name in your source
tree that is full of files you don't want installed. It also avoids
splitting the name in two and listing them in the wrong order.
You can also set the install mode of each directory component by listing
them one at a time in order, and in fact create nested structures at
all.
Fixes#1604
Properly fixes#2904
UseMultiToolTask allows parallelism inside a project, without requiring cl.exe
internal multi-threading (which meson generated projects currently can't use,
mainly due to specifying output filenames for each object).
TODO:
- think about making behaviour conditional on msbuild version / add comment
why not
The main reason for this move is to make it easier to merge the copies of
project generation. But as far as I can tell, the Microsoft.Cpp.props import
also belongs before the ItemDefinitionGroup.
Originally the order seems to have been that way, but 431a9ea664 changed it in
the course of other changes.
This patch adds a new meson built-in option for cython, allowing it to
target C++ instead of C as the intermediate language. This can, of
course, be done on a per-target basis using the `override_options`
keyword argument, or for the entire project in the project function.
There are some things in this patch that are less than ideal. One of
them is that we have to add compilers in the build layer, but there
isn't a better place to do it because of per target override_options.
There's also some design differences between Meson and setuptools, in
that Meson only allows options on a per-target rather than a per-file
granularity.
Fixes#9015
This really is more of a struct than a dict, as the types are disjoint
and they are internally handled, (ie, not from user input). This cleans
some things up, in addition I spotted a bug in the ModuleState where the
dict with the version and license is passed to a field that expects just
the version string.
When setup creates a Visual Studio environment, a message is logged
which contains a path to the build directory. Typically, this path is
converted to a relative path prior to printing. If the path cannot be
converted to a relative path (e.g., because buildpath is on a different
drive from the cwd), print out the full path instead of failing with an
unhandled exception.
When a static library B to a static library A with generated sources, B
directly references the object file corresponding to the generated source in
A. For that reference in B object_filename_from_source() is used. But A did
not specify the object file name, ending up with cl.exe's default.
Fixes: #9235
Since we changed to using a json file to avoid over long command lines
we created a situation where the generated files may not be ready when
the depscan happens. To avoid that, we need to add all of the generated
sources as order deps.
Fixes: #9258
Declan Qian
Nirbheek Chauhan
Dylan Baker
Paolo Bonzini
complexoctonion
Eli Schwartz
Pablo Correa Gómez
Luke Elliott
Crend King
GustavoLCR
Moroz Oleg
Олег Мороз
Jussi Pakkanen
Xavier Claessens
Christian Clauss
Andres Freund
Ryan Kuester