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.
Don't assume itstool, msgfmt et al. are just magically on the path.
Normally for commands being processed in build.ninja we'd look up the
program in order to run it. Offer the same guarantee for programs being
passed through an awkward script wrapper.
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.
It makes no sense to specify both:
- install_dir, which overrides the -Dincludedir= builtin option
- subdir, which suffixes the -Dincludedir= builtin option
We've always silently ignored the subdir in this case, which is really
surprising if someone actually passed it and expected it to do
something. We also confusingly didn't say anything in the documentation
about it.
Document that the options are incompatible, and explicitly check to see
if they are both passed -- if so, raise an error message pointing out
that only install_dir should be used.
Fixes#10046
JNI is a more apt name because it currently only supports the JNI. I
also believe that CMake uses the terminology JNI here as well.
JNI is currently the only way to interact with the JVM through native
code, but there is a project called "Project Panama" which aims to be
another way for native code to interact with the JVM.
GCC with optimization set to 0 does not actually result in no
optimizations, which can be annoying when trying to use a debugger like
gdb, and finding that your variable has been optimized out. We already
do this with clang, so gcc is a bit of an outlier here.
Unfortunately, checking for strings without context is exceedingly prone
to false positives, while missing anything that indirectly opens a file.
Python 3.10 has a feature to warn about this though -- and it uses a
runtime check which runs at the same time that the code fails to open
files in the broken Windows locale. Set this up automatically when
running the testsuite.
Sadly, Python's builtin feature to change the warning level, e.g. by
setting EncodingWarning to error at startup, is utterly broken if you
want to limit it to only certain modules. This is tracked in order to be
more efficiently ignored at https://bugs.python.org/issue34624 and
https://github.com/python/cpython/pull/9358
It is also very trigger happy and passing stuff around via environment
variable either messes with the testsuite, or with thirdparty programs
which are implemented in python *such as lots of gnome*, or perhaps
both.
Instead, add runtime code to meson itself, to add a hidden "feature".
In the application source code, running the 'warnings' module, you can
actually get the expected behavior that $PYTHONWARNINGS doesn't have. So
check for a magic testsuite variable every time meson starts up, and if
it does, then go ahead and initialize a warnings filter that makes
EncodingWarning fatal, but *only* when triggered via Meson and not
arbitrary subprocess scripts.
We didn't consider that it has arguments following it, so the resulting
compiler command line ended up with stuff like:
-L=-rpath-link -L=-L=/path/to/directory -L=more-args
and the directory for rpath-link got eaten up as a regular -L path to
the compiler rather than being passed as -Xlinker to the linker.
Then the -rpath-link would consume the next -Xlinker argument, end up
with the wrong rpath-link (may or may not cause link errors) and then
disappear arguments we need.
As an example failure mode, if the next argument is -soname this treats
the soname text as an input file, which probably does not exist if it
was generated in a subdirectory, and also because it can never be
successfully built in the first place -- though if it did, it would link
to itself which is very wrong.
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.
It's a dumb check which doesn't know the difference between python
functions and string data. Work around this by changing the message
output to not include an opening parenthesis, and changing other similar
strings the same way for consistency.
All these dependencies are impossible to find on versions of Meson older
than the ones they got custom lookups in, because they don't provide
pkg-config files. So they should not / cannot be reasonably used on
older versions, and it is easy to say "yep, these should emit a
FeatureNew for the versions they got added in".
It would be too difficult and probably a layering violation to give an
interpreter handle to the inner guts of every dependency. What we can do
instead is let every dependency track:
- the Feature checks it can produce,
- the version attribute for when it was implemented
while leaving the interpreter in charge of actually emitting them.
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.
When the project instals GDB helper scripts, copy them into
meson-private directory with the right tree layout and write a .gdbinit
script to load them automatically.
The documentation on how shaderc is checked in meson was quite behind.
Update it to mention that pkg-config is the default and preferred method
of checking. Also be specific about what order everything is checked in
since shaderc is confusing.
Do not traceback when trying to update a wrap that isn't a [wrap-file],
just report the problem.
Do not traceback on perfectly valid WrapDB wraps that don't have a
patch_url because they have upstream meson.build, instead try to parse
the version from the source tarball filename.