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.
Xavier Claessens
Eli Schwartz
Dylan Baker
Mark Bolhuis
Thomas Lange
0xMRTT
Gerion Entrup
Philip Withnall
Michael Davidsaver
Amit D
Jussi Pakkanen
smowzy
CLanguagePurist
ff
Paweł Marczewski