Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
The documentation for build_target(...) does not list file or str as
the possible types for the "objects" keyword argument, even though in
theory the argument is meant for prebuild object files that are part
of the sources.
Of course that is only the theory, because an ExtractedObjects object
is probably used a lot more than a file in the source tree. But
at least make the reference manual's typing information accurate.
Link to feature options consistently, and point out that it controls
"whether" the function finds what it's trying to find. This clues people
in to the fact that disabled features exist.
I accidentally followed a very old link and was briefly discombobulated.
To save other people from this mistake, use the current location
of the Meson repository, and tweak the surrounding text so it is
more clear that it was written nearly 10 years ago.
Signed-off-by: Tony Finch <dot@dotat.at>
Claiming that "it should literally never be used ever no matter what" is
confusing and wrong -- it's definitely useful sometimes, but does result
in downsides, like not tracking inter-target dependencies correctly.
Ref: #10901
Adds a new maximum warning level that is roughly equivalent to "all warnings".
This adds a way to use `/Wall` with MSVC (without the previous broken warning),
`-Weverything` with clang, and almost all general warnings in GCC with
strictness roughly equivalent to clang's `-Weverything`.
The GCC case must be implemented by meson since GCC doesn't provide a similar
option. To avoid maintenance headaches for meson, this warning level is
defined objectively: all warnings are included except those that require
specific values or are specific to particular language revisions. This warning
level is mainly intended for new code, and it is expected (nearly guaranteed)
that projects will need to add some suppressions to build cleanly with it.
More commonly, it's just a handy way to occasionally take a look at what
warnings are present with some compiler, in case anything interesting shows up
you might want to enable in general.
Since the warnings enabled at this level are inherently unstable with respect
to compiler versions, it is intended for use by developers and not to be set as
the default.
-Wnon-virtual-dtor is not what people think of as a standard warning
flag. It was previously removed from -Wall in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16190 on the grounds that
people didn't like it and were refusing to use -Wall at all because it
forced this warning. Instead, it is enabled by -Weffc++ which is
typically not enabled and even comes with GCC documentation warnings
stating that the standard library doesn't obey it, and you might need to
`grep -v` and filter out warnings. (!!!)
It doesn't fit into the typical semantics of Meson's warning_level
option, which usually aligns with compiler standard warning levels
rather than a niche ideological warning level.
It was originally added in commit 22af56e05a,
but without any specific rationale included, and has gone unquestioned
since then -- except by the Meson users who see it, assume there is a
finely crafted design behind it, and quietly opt out by rolling their own
warning options with `add_project_arguments('-Wall', ...)`.
Furthermore a GCC component maintainer for the C++ standard library
opened a Meson bug report specially to tell us that this warning flag is
a "dumb option" and "broken by design" and "doesn't warn about the right
thing anyway", thus it should not be used. This is a reasonably
authoritative source that maybe, just maybe, this flag... is too
opinionated to force upon Meson users without recourse. It's gone beyond
opinionated and into the realm of compiler vendors seem to think that
the state of the language would be better if the flag did not exist at
all, whether default or not.
Fixes#11096
- qt5 -> qt6
- remove version information from when the Qt6 module was not a thing
- linked to dependency function
- highlight version information with *...* and placing it at the front of options or on new lines in text
- reformatted for shorter lines
Fixes:
- Incorrect, redundant, or overabundant usage of "just"
- Missing punctuation
- Missing "the"
- Parenthesized text far from what it describes
There are some subjective changes, I hope those aren't controversial.
This is based on searching for `@FeatureNew*` decorators.
There is also one correction to a version in a decorators;
`build_by_default` was added in #1303, which is 0.38.0, not 0.40.0.
https://github.com/mesonbuild/meson/pull/9287 changed the `optimization=0`
to pass `-O0` to the compiler. This change is reasonable by itself
but unfortunately, it breaks `buildtype=plain`, which promises
that “no extra build flags are used”.
`buildtype=plain` is important for distros like NixOS,
which manage compiler flags for optimization and hardening
themselves.
Let’s introduce a new optimization level that does nothing
and set it as the default for `buildtype=plain`.
It is common, at least in GNOME projects, to install tests. Files goes
into various locations, including:
- /usr/lib/x86_64-linux-gnu/installed-tests
- /usr/share/installed-tests
- /usr/libexec/installed-tests
It is safe to assume that everything that goes into a "installed-tests"
subdir should be tagged as "tests" by default.
This allows early exit of the project tests once a certain number of
failures are detected. For example `meson test --maxfail=1` will abort
as soon as a single test fails.
Currently running tests are marked as failed via INTERRUPT.
Resolves#9352
When at least one Rust target is present, we now generate a
rust-project.json file, which can be consumed by rust-analyzer. This is
placed in the build directory, and the editor must be configured to look
for this (as it is not a default search path).
GLib installs a few executables that are not needed by applications that
use the glib libraries, but are used either by build systems or by user
scripts. Debian splits them into libglib2.0-dev-bin and libglib2.0-bin
packages. Another example is GStreamer tools (e.g. gst-launch-1.0) that
Debian packages separately in gstreamer1.0-tools.
It is common enough that Meson documentation should recommend a tag for
consistency across projects.
wayland-scanner can generate header files that only include
wayland-client-core.h using a flag.
Add a core_only option to scan_xml to support this use case.
We mention --cross-file in the relevant page, but the fact that
--native-file is the command line argument to use is mentioned nowhere
other than a couple of release notes and the --help text for meson
setup.
This should be described in the docs.
This is generally a bad idea, e.g. it causes OSError on freebsd.
It also gets ignored by solaris and thus causes unittest failures.
The proper solution is to simply reject any attempt to set this, and log a
warning.
The install_emptydir function does apply the mode as well, and since it
is a directory it actually does something. This is the only place where
we don't reset the mode.
Although install_subdir also installs directories, and in theory it
could set the mode as well, that would be a new feature. Also it doesn't
provide much granularity and has mixed semantics with files. Better to
let people use install_emptydir + install_subdir.
Fixes#5902
`configure_file` is both an extremely complicated implementation, and
a strange place for copying. It's a bit of a historical artifact, since
the fs module didn't yet exist. It makes more sense to move this to the
fs module and deprecate this `configure_file` version.
This new version works at build time rather than configure time, which
has the disadvantage it can't be passed to `run_command`, but with the
advantage that changes to the input don't require a full reconfigure.
This is ambiguous, if the build directory has the same name as a
subcommand then we end up running the subcommand. It also means we have
a hard time adding *new* subcommands, because if it is a popular name of
a build directory then suddenly scripts that try to set up a build
directory end up running a subcommand instead.
The fact that we support this at all is a legacy design. Back in the
day, the "meson" program was for setting up a build directory and all
other tools were their own entry points, e.g. `mesontest` or
`mesonconf`. Then in commit fa278f351f we
migrated to the subcommand mechanism. So, for backwards compatibility,
we made those tools print a warning and then invoke `meson <tool>`. We
also made the `meson` tool default to setup.
However, we only warned for the other tools whose entry points were
eventually deleted. We never warned for setup itself, we just continued
to silently default to setup if no tool was provided.
`meson setup` has worked since 0.42, which is 5 years old this week.
It's available essentially everywhere. No one needs to use the old
backwards-compatible invocation method, but it continues to drag down
our ability to innovate. Let's finally do what we should have done a
long time ago, and sunset it.
custom_target allows selective installation if it outputs more than one
file. Mention this explicitly in install.
Additionally, fix the types for install_dir.
see: https://github.com/mesonbuild/meson/issues/505
It saves bandwidth and disk usage on downloaded subprojects, and people
very rarely need more than the single commit they’re using.
Add `depth=1` to the `[wrap-git]` examples in the rest of the
documentation, to make it more likely that people will copy-and-paste it
into their `.wrap` files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We want to talk about the kwargs to the custom_target() function, but
tried to link to custom_tgt instead, which is not a function. It is an
object, but this was the wrong reference method for a type.
We want the function anyway, so use that.
The end of the paragraph indicates that the options which support --foo
will be listed in the help text. The beginning of the paragraph seems to
suggest the same thing, except it doesn't distinguish between -Dfoo and
--foo style options.
The first mention is redundant and feels like the wrong part of the
paragraph to mention it anyway.
With the previous commit, we made this smartly detect when parentheses
are not needed. But the example was broken, because it doesn't follow
its own documented rules to use `[[#` syntax. Add the missing hash
character.
If we link to
```meson
[[#function]]('posarg')
```
then the ideal linkification would operate on "function" in the
formatted text:
```
function('posarg')
```
Instead, it operated on "function()" in the formatted text:
```
function()('posarg')
```
Fix this by detecting the next character after the reference, and
skipping the usual "automatically append the () for you" stage if it
already has that opening parenthesis.
The unit test was racy but surprisingly never failed on CI. The reason
is we need to ensure ninja build somelib.so before running `make` into
the external project.
Dlang uses both integer version "levels" and arbitrary string
identifiers, and we support both, but don't mention it in the docs.
Also update a test case to pass one via declare_dependency. We already
test this kwarg for build_target.
The type information is clearly wrong as it disagrees with the
description w.r.t. generated headers.
We also rely on it accepting custom targets for the obvious reason that
we accept it in a build target too! In fact, we rely on this in the
testsuite too.
Merging snippets happens in arbitrary order -- whatever filesystem
globbing results in. This didn't matter too much when we ran it once at
release time and checked the resulting release notes into git. However,
now that we generate a temporary version of the release notes for
development versions, the order of the results will periodically change.
Sort the files before processing them in order to guarantee that
whatever order they are in, they stay that way.
As a side effect, it's now technically possible to guarantee an ordering
by judicious use of snippets naming.
Leak sanitizer can be enabled without the whole AddressSanitizer, this
can be done by passing -fsanitize=leak as documented at [1].
Meson doesn't support this, so add support for it.
[1] https://clang.llvm.org/docs/LeakSanitizer.html
Logically, i18n.merge_file cannot ever take a MULTI_OUTPUT_KW, but it
does take a CT_OUTPUT_KW-like interface.
Actually trying to pass multiple merge_file outputs causes the
msgfmthelper script to be entirely malformed in the arguments it
accepts, and treat the broken one like a --flag, then exit with argparse
errors.
Even if we somehow assumed that somehow it was designed to actually
allow this, msgfmt doesn't support conceptually passing multiple outputs
so that would be a msgfmt error instead of an error inside the guts of
`meson --internal msgfmthelper`.
Same logic applies again for the itstool command and the itstool
internal helper.
Catch this error at configuration time by using the single-output kwarg
form.
Likewise, it's totally nonsense to accept multiple install_dir or
install_tags, and ever since commit 11f9638035
the CustomTarget itself won't even check this.
The `install_headers` function now has an optional argument
`preserve_path` that allows installing multi-directory
headerfile structures that live alongside sourcecode with a
single command.
For example, the headerfile structure
headers = [
'one.h',
'two.h',
'alpha/one.h',
'alpha/two.h',
'alpha/three.h'
'beta/one.h'
]
can now be passed to `install_headers(headers, subdir: 'mylib', preserve_path: true)`
and the resulting directory tree will look like
{prefix}
└── include
└── mylib
├── alpha
│ ├── one.h
│ ├── two.h
│ └── three.h
├── beta
│ └── one.h
├── one.h
└── two.h
Fixes#3371
python compiled extensions should never need to expose any symbol other
than PyInit_* which is declared with default visibility via
PyMODINIT_FUNC on supported compilers.
Thus, a reasonably sane default is to mark any other symbols as hidden,
while still respecting any manually specified visibility.
Gate this on the version of python itself, as not all versions decorate
PyMODINIT_FUNC properly.
Otherwise it always returns the value for c++98, starting with MSVC 2017
15.7 or later. Earlier versions are not affected by this mis-feature.
See: https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160
This was originally applied as 0b97d58548
but later reverted because it made the CI red. Try it again, now.
Original-patch-by: Dylan Baker <dylan@pnwbakers.com>
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
gcovr will read this file anyway, but if it exists we don't need to
assume that the project wishes to exclude subprojects/ -- they can
determine that themselves.
Fixes#3287Closes#9761
lcov doesn't read the config file by default, but we can do the smart
thing here.
Fixes#4628
By default, meson will try to look for shared libraries first before
static ones. In the meson.build itself, one can use the static keyword
to control if a static library will be tried first but there's no simple
way for an end user performing a build to switch back and forth at will.
Let's cover this usecase by adding an option that allows a user to
specify if they want dependency lookups to try static or shared
libraries first. The writer of the meson.build can manually specify the
static keyword where appropriate which will override the value of this
option.
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
In the original RefMan 2.0 implementation, the types for this were
filled in as `str | file`, but the code only ever accepted the former.
Fix the documentation so that it aligns with reality.
Fixes#10338
+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
[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>
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.
- 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.
It isn't possible to have one target depend on a run_target, because
those produce no outputs and are always out of date. But the docs didn't
specify which types of target are valid here.
Correct the docs to align with the implementation.
Fixes#10198
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.
This reverts commit 79c6075b56.
# Conflicts:
# docs/markdown/snippets/devenv.md
# mesonbuild/modules/python.py
# test cases/unit/91 devenv/test-devenv.py
PYTHONPATH cannot be reliably determined. The standard use case for
installing python modules with Meson is mixed pure sources (at least
`__init__.py`) and compiled extension_modules or configured files.
Unfortunately that doesn't actually work because python will not load
the same package hierarchy from two different directories, one a source
directory and one a (mandatory) out of tree build directory.
(It kind of can, but you need to do what this test case accidentally
stumbled upon, which is namespace packages. Namespace packages are a
very specific use case and you are NOT SUPPOSED to use them outside that
use case, so people are not going to use them just to circumvent Meson
devenv stuff as that would have negative install-time effects.)
Adding PYTHONPATH anyway will just lead to documentation commitments
which we cannot actually uphold, and confusing issues at time of use
because some imports *will* work... and some will *not*. The end result
will be a half-created tree of modules which just doesn't work together
at all, but because it partially works, users attempting to debug it
will spend time wondering why parts of it do import.
For any case where the automatic devenv would work correctly, it will
also work correctly to use `meson.add_devenv()` a single time, which is
very easy to manually get correct and doesn't provide any significant
value to automate.
In the long run, an uninstalled python package environment will require
"editable installs" support.
This reverts commit e257a870fe.
The PR adding this command had infinitely hanging CI, and now that it is
merged to master we cannot get any CI on any PR to succeed.
It is often useful to check the found version of a program without
checking whether you can successfully find
`find_program('foo', required: false, version: '>=XXX')`
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
- 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.
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.
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.
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.
stdout line matching supports count since commit
66d62a224e to fail if certain output is
present (count: 0) but it was never documented in the contribution
guidelines.
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.
Android requires shared modules that use symbols from other shared
modules to be linked before they can be dlopen()ed in the correct
order. Not doing so leads to a missing symbol error:
https://github.com/android/ndk/issues/201
We need to always allow linking for this. Also add a soname, although
it's not confirmed that it's needed, and it doesn't really hurt if it
isn't needed.
This bring us in line with Autotools and CMake and it is useful
for platforms like Nix, which install projects
into multiple independent prefixes.
As a consequence, `get_option` might return absolute paths for some
directory options, if a directory outside of prefix is passed.
This is technically a backwards incompatible change but its effect
should be minimal, thanks to widespread use of `join_paths`/`/` operator
and pkg-config generator module. It should only cause an issue when
a path were constructed by concatenating the value of directory path option.
Also remove a comment about commonpath since we do not use that since
<00f5dadd5b>.
Fixes: https://github.com/mesonbuild/meson/issues/2561
The array of licenses is not clear, where and SPDX expression using AND
and OR is very clear, take for example this: `['Apache', 'GPLv2']`. What
does that mean? Any Apache license you like and GPLv2? Using a valid
SPDX license identifier however makes it extremely clear what is meant:
`'Apache-2.0 OR GPL-2.0-only'`. It is very clear that you mean, "this is
Apache 2.0, however, you can use as GPL-2.0 for the purpose of linking
it into your GPL-2.0 project".
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.
This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes#9721
Regressed in commit bfb12222c3.
This needs to iterate over all methods, process them, and add them to a
list. Instead, it deleted all methods, processed all remaining methods,
and appended them to the in-use iterator.
Use a second list, instead.
Fixes#9922
Do not recommend running the 'upload' target by default in order to
build the docs. That will fail with permission errors when trying to
push to a repo most people don't have commit access to, and if they did
have commit access it would be an even worse problem -- unpredictably
overwriting the main website without any guarantee it was generated from
the latest version of the docs!
Plus, it does not actually work. The first thing it does is spawn an
error message that required files do not exist, because the actual docs
were not, in fact, built. So they cannot be uploaded either.
The docs will build by default if you do not specify a non-default
target.
Fixes#9873
This is currently allowed, and is used in at least a few projects. It
was not intended to work or documented, but it does and since it is in
use a full deprecation period must be used. A warning has also been
added for values < 0, which have surprising behavior.
It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
Dylan Baker