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.
This moves generally useful logic from GNOME module's
_get_native_binary() into find_program() implementation. We could decide
later to expose it as public API.
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
We currently don't handle subdirectories correctly in
structured_sources, which is problematic. To make this easier to handle
correctly, I've simply changed `structured_sources` to only use Files
and not strings as an implementation detail.
We need this for the python module, as implemented in commit
e8375d20a9, but that then crashed in
subprojects because those options were never forwarded to the subproject
interpreter.
We are supposed to fallback on the fallback when running the vcstagger,
but instead we errored out during configure.
Fixes regression in commit b402817fb6.
Before this, we used shutil.which || relative paths, and in the latter
case if it could not be found we still wrote out that path but it failed
to run in vcstagger. Now, we use find_program under the hood, so it
needs to be run in non-fatal mode, and if it is not found, we simply
keep the original command string. It's a VCS command, so if we magically
end up finding it at runtime because it was installed after running
configure, that is *fine*.
It used to be possible to do this:
```
bomb = find_program('nonexisting', required: false)
test('traceback during meson test', bomb)
```
and it would in fact bomb out, with:
```
[0/1] Running all tests.
Traceback (most recent call last):
File "/usr/lib/python3.10/site-packages/mesonbuild/mesonmain.py", line 149, in run
return options.run_func(options)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 2017, in run
return th.doit()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1685, in doit
runners.extend(self.get_test_runner(test) for test in tests)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1685, in <genexpr>
runners.extend(self.get_test_runner(test) for test in tests)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1586, in get_test_runner
return SingleTestRunner(test, env, name, options)
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1308, in __init__
self.cmd = self._get_cmd()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1374, in _get_cmd
test_cmd = self._get_test_cmd()
File "/usr/lib/python3.10/site-packages/mesonbuild/mtest.py", line 1352, in _get_test_cmd
if self.options.no_rebuild and not os.path.isfile(testentry):
File "/usr/lib/python3.10/genericpath.py", line 30, in isfile
st = os.stat(path)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType
ERROR: Unhandled python exception
This is a Meson bug and should be reported!
```
This is something we explicitly check for elsewhere, for example when
using a not-found program as a command in a custom target or generator.
Check for it when making a test too, and error out with a similar error.
Fixes#10091
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
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
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.
We do not want anyone touching this entire directory tree, but due to
the way it was implemented, we only checked if its direct parent was a
subproject violation. This generally worked, unless people tried to add
`subprojects/` as an include directory.
Patch this hole. It now provides the same warning any sandbox violation
does (but is not currently an error, just a "will become an error in the
future").
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!
The utility function that processes this for both 'variables' and
'uninstalled_variables' accepts a kwarg for the name of the argument,
but then hardcodes 'variables' in the warning message. This is
misleading.
In commit 06481666f4 this warning got
moved from build.py to the interpreter. Unfortunately it got added to
the wrong function... it is supposed to be part of custom_target and
even mentions this as the feature_name.
Since then, build_always became a KwargInfo and has the deprecated-since
attribute baked into it. But it didn't have the additional message which
it really should have.
Add that message at the same time we remove it from vcs_tag.