We need to setup the environment we pass to g-ir-scanner because it will
try to use pkg-config to find dependencies, and that must respect user
settings from machine file. Also make it use uninstalled pc files Meson
generated in the case dependencies, such as glib, have been built as
subproject.
The new get_env() method that returns an EnvironmentVariables object
will be needed in next commit that will pass it to CustomTarget.
This has the side effect to use the proper os specific path separator
instead of hardcoding `:`. It is the obvious right thing to do here, but
has caused issues in the past. Hopefully issues have been fixed in the
meantime. If not, better deal with fallouts than keep doing the wrong
thing forever.
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Regression in commit 11f9638035. When
`install: true` the install_dir must be set. The CustomTarget
initializer no longer checks this for us, so we must include the check
ourselves.
Regression in commit 11f9638035. We expect
exactly one string as an install_dir, but CustomTarget started expecting
it to be a list. So we need to pass it as such when forwarding
compile_translations() arguments to the CustomTarget initializer.
Nothing elaborate, just laying down the ground rules for expected usage
and pointing out that it now works. The idea is not to give people
ideas, but to let projects which already have this use case, use it with
confidence.
The compiler flag only exists on Visual Studio 2015 or later, or clang-cl,
and using this always can interfere with compiler feature detection when
this flag is not supported.
So, remove '/utf-8' from always_args if we are on Visual Studio 2013 or
earlier.
This way, we can ensure that gtk-doc parses the --path argument
correctly when passed in from the cmd.exe console, since ':' is normally
used to denote that a drive is being used on local paths.
- Documentation for the pkgconfig.relocatable module option in
Builtin-options. Gives an explanation on what it does, usefulness and
what error that can occur when using it.
- Add pkgconfig.relocatable release snippet. Similar to the
documentation in Builtin-options. Just a bit more brief.
- Add Pkgconfig to DataTests.test_builtin_options_documented in the
docs unit tests.
If set to true it will generate the pkgconfig files as relocatable i.e
the prefix variable will be relative to the install_dir. By default
this is false.
Will generate a MesonException if the pkgconfig file is installed
outside of the package and pkgconfig.relocatable=true.
We can immediately short-circuit if there is no destdir, as we simply
return the prefix unchanged.
If there is some kind of destdir and the prefix contains a drive letter,
then no matter what we need to remove the drive letter before joining.
Technically, if the destdir is a relative path e.g. `destdir\` and
`C:\prefix`, we should still install to `destdir\prefix` without the
drive letter.
But... we also guarantee that destdir is an absolute path (or empty)
anyway. And even if we didn't, non-absolute destdir is a broken concept
for a variety of complicated reasons. So none of this matters in
practice.
One way or another, we don't need to actually check whether destdir is
an absolute path before cutting off the prefix drive letter.
It's a bit annoying having to *manually* disable a workflow for forks,
because the scheduled build is a waste of time and also spammy.
On the other hand, having the workflow enabled is in general a good
thing, because it is in fact desirable to test it locally in forks.
In commit f291b637b1 the tools were moved
around but a comment got forgotten. Now, in order to be meaningful and
remind us of anything, it needs to be in a different location.
This allows tracking which subproject it came from at the time of
definition, rather than the time of use. As a result, it is no longer
possible for one subproject which knows that another subproject installs
some data files, to expose those data files via its own
declare_dependency.
There are somewhat common, reasonable and legitimate use cases for a
dependency to provide data files installed to /usr which are used as
command inputs. When getting a dependency from a subproject, however,
the attempt to directly construct an input file from a subproject
results in a sandbox violation. This means not all dependencies can be
wrapped as a subproject.
One example is wayland-protocols XML files which get scanned and used to
produce C source files.
Teach Meson to recognize when a string path is the result of fetching a
dep.get_variable(), and special case this to be exempt from subproject
violations.
A requirement of this is that the file must be installed by
install_data() or install_subdir() because otherwise it is not actually
representative of what a pkg-config dependency would provide.
dep.get_variable() only supports string values for pkg-config and
config-tool, because those interfaces use text communication, and
internal variables (from declare_dependency) operate the same way.
CMake had an oddity, where get_variable doesn't document that it allows
list values but apparently it miiiiiight work? Actually getting that
kind of result would be dangerously inconsistent though. Also, CMake
does not support lists so it's a lie. Strings that are *treated* as
lists with `;` splitting don't count...
We could do two things here:
- raise an error
- treat it as a string and return a string
It's not clear what the use case of get_variable() on a maybe-list is,
and should probably be a hard error. But that's controversial, so
instead we just return the original `;`-delimited string. It is probably
the wrong thing, but users are welcome to cope with that somehow on
their own.
Maple
Jussi Pakkanen
zxey
Xavier Claessens
Remi Thebault
Fini Jastrow
Eli Schwartz
Ferdinand Thiessen
Paolo Bonzini
Chun-wei Fan
Simon Arlott
Kirill Isakov
Thomas Klausner
Fredrik Salomonsson
Sergey Fedorov
barracuda156
Daniel Mensinger
Peter Lesslie
Ben Brown