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.
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.
String formatting should validly assume that printing a list means
printing the list itself. Instead, something like this broke:
'one is: @0@ and two is: @1@'.format(['foo', 'bar'], ['baz'])
which would evaluate as:
'one is: foo and two is: bar'
or:
'the value of array option foobar is: @0@'.format(get_option('foobar'))
which should evaluate with '-Dfoobar=[]' as
'the value of array option foobar is: []'
But instead produced:
meson.build:7:0: ERROR: Format placeholder @0@ out of range.
Fixes#9530
This reverts commit c0efa7ab22.
This was a nice idea, or a beautiful hack depending on your perspective.
Unfortunately, it turns out to be a lot harder than we originally
thought. By operating on bare nodes, we end up triggering a FeatureNew
on anything that isn't a string literal, rather than anything that
isn't a string.
Since no one else has come up with a better idea for implementing a
FeatureNew, let's just revert it. Better to not have a warning, than
have it trigger way too often.
Another commit in my quest to rid InterpreterBase from all higher
level object processing logic.
Additionally, there is a a logic change here, since `str.join` now
uses varargs and can now accept more than one argument (and supports
list flattening).
Xavier Claessens