Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
This can be useful to make sure that a project builds when
its fallbacks are used on systems where external dependencies
satisfy the version requirements, or to easily hack on the sources
of a dependency for which a fallback exists.
Sometimes it is needed to run the current compiler with specific options
not to compile a file but rather to obtain additional info. For example,
GCC has several -print-* options to query it about the paths to
different libraries and development files. One use case is to get the
location of development files for GCC plugins, which is not easily
obtainable by other means:
gcc -print-file-name=plugin
For this purpose, it would be convenient if the compiler object returned
by meson.get_compiler(lang) could be used in run_command() directly.
This commit implements it.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
When building a Rust target with Rust library dependencies, an
`--extern` argument is now specified to avoid ambiguity between the
dependency library, and any crates of the same name in `rustc`'s
private sysroot.
Includes an illustrative test case.
The documentation doesn't require it and the interpreter code works around the
possibility of it being None. The ninja backend code however fails with
File "/home/whot/code/meson/mesonbuild/backend/ninjabackend.py", line 796, in generate_data_install
dstabs = os.path.join(subdir or None, plain_f)
File "/usr/lib64/python3.6/posixpath.py", line 78, in join
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType
If install_dir is missing, default to datadir/projectname
This allows for much easier cross compiler configuration for tools like
LLVM. This patch does honor the 'native' keyword, and falls back to
searching PATH if the binary name is not specified.
I'd be fine with either removing the fallback behavior, or marking it as
deprecated and removing it later.
Fixes#2921
One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.