run_target() does some variable substitutions since 0.57.0. This is a
new behavior, and undocumented, caused by sharing more code with
custom_target(). More consistency is better, so document it now.
custom_target() was doing variable substitution in the past, because it
shared some code with generator(), but that was undocumented. Some
refactoring in 0.57.0 caused it to not replace @CURRENT_SOURCE_DIR@,
@SOURCE_DIR@, and @BUILD_DIR@ anymore. This patch adds back
@CURRENT_SOURCE_DIR@ and document it. It does not add back @SOURCE_DIR@
because it is duplicate with @SOURCE_ROOT@ that has a better name. Also
do not add back @BUILD_DIR@ which is duplicate of @PRIVATE_DIR@, and
not @BUILD_ROOT@ surprisingly, adding to the confusion.
install_subdir() with a non-existing subdir creates the directory in the
target directory. This seems like an implementation detail but is quite useful
to create new directories for e.g. configuration or plugins in the installed
locations.
git bisect says this started with 8fe8161014.
Let's add a test for it and document it to make this behavior official.
Limitation: it can only create at the install_dir location, trying to create
nested subdirectories does not work and indeed creates the wrong directory
structure. That is a bug that should be fixed separately:
install_subdir('blah',
install_dir: get_option('prefix'))
install_subdir('sub/foobar',
install_dir: get_option('prefix'))
install_subdir('foo/baz',
install_dir: get_option('prefix'))
$ tree ../_inst
../_inst
├── baz
├── blah
└── foobar
Fixes#2904
This has a couple of advantages over rolling it by hand:
1. it correctly handles include_directories objects, which is always
handy
2. it correctly generates a depfile for you, which makes it more
reliable
3. it requires less typing
Our approach to unity builds with vala is broken, you cannot unify the
generated C files, as they contain duplicate symbols. We would need to
instead combine the files while they are still in their vala form, then
convert that to C and compile the unified C file.
This does not fix the linked issue, as this removed the ability to do
vala unity builds, but it does allow running vala with `--unity=on`.
Related: #5280
Re-implement it in backend using the same code path as for
custom_target(). This for example handle setting PATH on Windows when
command is an executable.
Various GNOME projects have scripts that does similar task, better do it
directly in meson. This ensures it's done correctly regarding usage of
subprojects and pkg-config. See for example this gtk bug:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3626.
Fixes: #8268
Following #7890, this patch introduces the ability to read the contents
of a file to the fs module.
This patch introduces the ability to read files at configure time, but
has some restrictions:
- binary files are not supported (I don't think this will prove a
problem, and if people are wanting to do something with binary
files, they should probably be shelling out to their own script).
- Only files outside the build directory allowed. This limitation
should prevent build loops.
Given that reading an arbitrary file at configure time can affect the
configuration in almost arbitrary ways, meson should force a reconfigure
when the given file changes. This is non-configurable, but this can
easily be changed with a future keyword argument.
Both Clang and GCC support using multiple threads for preforming link
time optimizaions, and they can now be configured using the
`-Db_lto_threads` option.
Fixes#7820
This new keyword argument makes it possible to run specific
test setups only on a subset of the tests. For example, to
mark some tests as slow and avoid running them by default:
add_test_setup('quick', exclude_suites: ['slow'], is_default: true)
add_test_setup('slow')
It will then be possible to run the slow tests with either
`meson test --setup slow` or `meson test --suite slow`.
It is common, at least in GNOME projects, to have scripts that must be
run only in the final destination, to update system icon cache, etc.
Skipping them from Meson ensures we can properly log that they have not
been run instead of relying on such scripts to to it (they don't
always).
This commit performs some cleanup for the msvc and clang-cl arguments.
* "Disable Debug" (`/Od`) is no longer manually specified for optimization levels {`0`,`g`} (it is already the default for MSVC).
* "Run Time Checking" (`/RTC1`) removed from `debug` buildtype by default
* Clang-CL `debug` buildtype arguments now match MSVC arguments
* There is now no difference between `buildtype` flags and `debug` + `optimization` flags
The /ZI flag adds in "Edit and Continue" debug information, which will
cause massive slowdown. It is not a flag that we should be adding by
default to debug builds.
/Zi will still be added.
The new behavior of interrupting the longest running test with Ctrl-C is useful
when tests hang, but not when the run is completely broken for some reason.
Psychology tells us that the user will compulsively spam Ctrl-C in this case,
so exit if three Ctrl-C's are detected within a second.
aligning along the left is, I think, what most projects want to do.
Aligning along the middle looks subjectively ugly, and objectively
prevents me from further indenting an element, e.g.
Build information:
prefix : /usr
sysconfdir : /etc
conf file : /etc/myprogram.conf
It requires at least one option argument, and the one that provides
"basic information" about the project is --projectinfo, so let's use
that to demo the command.
Fixes#8182
* doc: fix hotdoc misuse for dynamically generated content
hotdoc has a native include feature for including files inline. Use this
to generate one file for each dynamically generated code block, and
include that file in Commands.md; see:
https://hotdoc.github.io/syntax-extensions.html#smart-file-inclusion-syntax
This permits us to move back to using the in-tree version of the hotdoc
*.md sources, thus fixing the incorrect inclusion of "builddir/" in the
"Edit on github" links which resulted from using copies as the source.
Fixes#8061
* doc: call the dummy file a "stamp" as it is a better known term
Like other language specific modules this module is module for holding
rust specific helpers. This commit adds a test() function, which
simplifies using rust's internal unittest mechanism.
Rust tests are generally placed in the same code files as they are
testing, in contrast to languages like C/C++ and python which generally
place the tests in separate translation units. For meson this is
somewhat problematic from a repetition point of view, as the only
changes are generally adding --test, and possibly some dependencies.
The rustmod.test() method provides a mechanism to remove the repatition:
it takes a rust target, copies it, and then addes the `--test` option,
then creates a Test() target with the `rust` protocol. You can pass
additional dependencies via the `dependencies` keyword. This all makes
for a nice, DRY, test definition.