Disabling targets because the tools used to build them aren't available
is a pretty suspicious thing to do. Users who want this are probably, in
general, advised to check themselves whether it is possible to build
those targets with find_program(..., required: false)
The i18n.gettext() invocation is a bit unusual because the product of
running it is non-critical files, specifically, translation catalogs. If
users don't have the tools needed to build them, they may not be able to
use them either, because perhaps they have NLS disabled on their
platform or it's difficult to put it in the bootstrap path.
So, for this reason, it was made non-fatal and the message catalogs are
just not created, and the resulting build is still perfectly usable
*unless* you want to use it in another language, at which point it
"works" but the text is all inscrutable to the end user, and that's a
feature of the target platform.
That's an acceptable tradeoff for translation catalogs.
It is NOT an acceptable tradeoff for merge_file, which produces desktop
files or MIME database catalogs or other files which have crucial roles
to perform, without which the software in question simply doesn't work
at all. In such cases, this just fails to install crucial files, users
report bugs to the project in question, and the project adds
`find_program('xgettext')` to guarantee the hard error due to lack of
confidence in Meson.
Fixes#6165Fixes#8436
Use this instead of shutil.which to detect whether they will be
available, and pass the ExternalProgram object to CustomTarget
invocations, or else make use of the new functionality to specify the
correct program path in wrapper scripts.
Drop duplicate reporting for itstool missing. Since we use find_program
in required mode, its absence is already fatal, and already has a really
good error description.
Due to misuse of argparse in commit 82492f5d76
it was impossible to use both --datadirs and extra args passed directly
to msgfmt at the same time.
I'm not sure anyone actually knows how argparse works, so misusing it is
easy. What is definitely known is that argparse is NOT a POSIX compliant
parser and doesn't behave the way you'd expect a standards based parser
to handle options. Instead it caters to the easy use case, and hopes and
prays you don't need to do anything too complicated "with the wrong kind
of complicated".
Apparently, this particular type of complicated is when you have mixed
option_arguments and operands while simultaneously passing some operands
as nargs after a --.
It totally breaks, and interprets --datadirs, which is supposed to be an
option_argument, as an operand, eats it up as a msgfmt wrapped argument,
and breaks.
But if you don't pass additional arguments with -- then it interprets
--datadirs after operands as an option_argument. This is what we were
doing.
Instead pass option_arguments before all operands (including the ones
specified via `-- ...`). Add test case to pass meaningless datadirs (we
don't actually care if $GETTEXTDATADIRS is set to something that doesn't
contain gettext data).
- Change `scope` kwarg to `public` boolean default to false.
- Change `side` kwarg to `client` and `server` booleans.
- Document returned values
- Aggregate in a single unit test because have lots of small tests
increases CI time.
Fixes: #10040.
After implementing a much more extensive Java native module than what
currently exists in the tests, I found shortcomings.
1. You need to be able to pass multiple Java files.
2. Meson needs more information to better track the generated native
headers.
3. Meson wasn't tracking the header files generated from inner classes.
This new function should fix all the issues the old function had with
room to grow should more functionality need to be added. What I
implemented here in this new function is essentially what I have done in
the Heterogeneous-Memory Storage Engine's Java bindings.
The point of a .use() function is because we don't always have the
information we need to use a feature check, so we allow creating the
feature and then storing it for later use. When implementing location
checks, although it is optional, actually using it violated that design.
Move the location out of the init method for FeatureCheck itself. It
remains compatible with all cases of .single_use(), but fix the rest up.
The default behavior of installing relative to prefix may be unexpected,
and is definitely wrong in many cases.
Give users control in order to specify that yes, they actually want to
install to a venv.
This is particularly useful for projects that use meson as a build
system for a python module, where *all* files shall be installed into
the python site-packages.
Automatically generate additional variables and write them into the
generated pkg-config file.
This means projects no longer need to manually define the ones they
use, which is annoying for dataonly usages (it used to forbid setting
the base library-relevant "reserved" ones, and now allows it only for
dataonly. But it's bloat to manualy list them anyway).
It also fixes a regression in commit
248e6cf473 which caused libdir to not be
set, and to be unsettable, if the pkg-config file has no libraries but
uses the ${libdir} expansion in a custom variable. This could be
considered likely a case for dataonly, but it's not guaranteed.
CMake's write_basic_package_version_file has supported since version 3.14
an ARCH_INDEPENDENT option that makes it skip its architecture check in
the Version file.
With this patch Meson now supports it as well, and the change is also
compatible with older CMake versions, as they will simply ignore the
option.
This also slightly changes the contents of the generated Version file
when arch_independent is not set: previously, the if() needed to skip
the arch check was always filled with an empty string, while CMake puts
"FALSE" (or "TRUE") in it. Now, that if() will always be filled with
either "False" or "True", better matching CMake's behaviour.
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
This was allows up to 0.61.0 (including with the initial type
annotations), but was accidentally broken by fixes for other bugs in
0.61.1.
Fixes: #9883
If the found python returns None from sysconfig.get_config_var('LIBPC')
then we cannot (and don't) set PKG_CONFIG_LIBDIR from it. In fact, we
can virtually guarantee we won't find a PkgConfigDependency either,
because any python that doesn't have a LIBPC is presumably not installed
to the system pkg-config directory (maybe it's an isolated relocatable
install, maybe it just doesn't have pkg-config support for who knows
what reason).
Trying to find one anyway using pkg-config's builtin search paths can
unexpectedly succeed, though, by finding a completely unrelated python
installation installed to a system location, which isn't the one we are
actually building for.
Instead, return early so that we use the system dependency class
fallback.
While we are at it, add back the debug messages from #3989 which got
removed.
Eli Schwartz
Xavier Claessens
Tristan Partin
Remi Thebault
Mark Bolhuis
Andrea Pappacoda
Dylan Baker
Bilal Elmoussaoui
Matthias Klumpp