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.
On Windows this would fail because of missing DLL:
```
mylib = library(...)
exe = executable(..., link_with: mylib)
meson.add_install_script(exe)
```
The reason is on Windows we cannot rely on rpath to find libraries from
build directory, they are searched in $PATH. We already have all that
mechanism in place for custom_target() using ExecutableSerialisation
class, so reuse it for install/dist/postconf scripts too.
This has bonus side effect to also use exe_wrapper for those scripts.
Fixes: #8187
we have two functions to do the exact same thing, and they're basically
implemented the same way. Instead, let's just use the BuildTarget one,
as it's more generally available.
Currently InstallDir is part of the interpreter, and is an Interpreter
object, which is then put in the Build object. This is a layering
violation, the interperter should have a Holder for build data. This
patch fixes that.
This is PEP8 convention for a const variable. Also, make the type
Mapping, which doesn't have mutation methods. This means mypy will warn
us if someone tries to change this.
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.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
I would have prefered to do these seperatately, but they are combined in
some cases, so it was much easier to convert them together.
this eliminates the builtins_per_machine dict, as it's duplicated with
the OptionKey's machine parameter.
See https://gitlab.gnome.org/GNOME/glib/-/issues/600
`volatile` was previously mistakenly used in GLib to indicate that a
variable was accessed atomically or otherwise multi-threaded. It’s not
meant for that, and up to date compilers (like gcc-11) will rightly warn
about it.
Drop the `volatile` qualifiers.
Based on a patch by Jeff Law.
See also http://isvolatileusefulwiththreads.in/c/.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The order of elements in sets cannot be relied upon, because the hash
values are randomized by Python. Whenever sets are converted to lists
we need to keep their order stable, or random changes in the command line
cause ninja to rebuild a lot of files unnecessarily. To stabilize them,
use either sort or OrderedSet. Sorting is not always applicable, but it
can be faster because it's done in C and it can produce slightly nicer
output.
Also, remove the possibility of passing in a compiler instance to
min_driver_version. This is because the NVCC compiler instance is,
as of CUDA Toolkit 11.0, no longer guaranteed to be versioned
identically to the toolkit itself.
This fix a regression caused by
https://github.com/mesonbuild/meson/pull/7837, it wanted to make
InternalDependency's external_deps private but has side effect of making
StatisLibrary's external_deps private too.
It is technically correct to make them private, but Meson used to make
StaticLibrary deps public so they are usable without `pkg-config
--static` when we know there is only a static library available.
Fixes: #7929.
It's an easy mistake to do this:
gir1 = gnome.generate_gir(...)
gir2 = gnome.generate_gir(...
includes: ['GObject-2.0', gir1])
This fails with an error:
ERROR: Gir includes must be str, GirTarget, or list of them.
The issue is that the 'gir1[0]' should be passed instead of 'gir1'.
To make the problem slightly clearly, tweak the error message to be:
ERROR: Gir includes must be str, GirTarget, or list of them. Got TypelibTarget.
This fixes glib-2.0-uninstalled.pc file.
GLib does `extra_cflags : ['-I${libdir}/glib-2.0/include']` because some
of its headers gets installed there. But when used uninstalled that path
makes no sense and pkg-config aborts because ${libdir} is not defined.
This cannot be worked around by GLib because Meson does not allow
setting different `extra_cflags` for -uninstalled.pc, and does not allow
setting libdir in `uninstalled_variables`.
When glib is a subproject we should use glib-compile-resources it
overrides using find_program() in the case it is not installed on the
build machine. With old glib version we have to run
glib-compile-resources at configure time to generate the list of
dependencies, but not when glib is recent enough.
This fixes a regression introduced by
https://github.com/mesonbuild/meson/pull/7488.
InternalDependency's ext_deps previously where simply ignored, but that
PR has effect to add many more public Requires in generated pc files.
When building with vs2019 (not ninja), a path length error will be thrown
if the path to a resource file is even remotely deep within the tree.
This is largely because the target name includes the string "Windows
resource for file 'full path'", which is then expanded twice (once for
the .vcxproj itself, and once for IntDir) and added to the full path.
When combined with the tiny path limits on Windows, it is easy to exceed
path limits.
This error is largely avoided by the ninja back-end. Unlike the
vs back-end, the ninja back-end does not use target.get_id() as part of
the project file path, nor does it use target.get_id() as part of
get_target_private_dir().
Example error:
error MSB4184: The expression "[MSBuild]::NormalizePath(
C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp,
f3f7317@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\,
f3f7317@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus.
vcxproj.CopyComplete)" cannot be evaluated. Path:
C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp\f3f7317
@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\f3f7317
@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus.
vcxproj.CopyComplete exceeds the OS max path limit.
The fully qualified file name must be less than 260 characters.
When building with vs2019 (not ninja), a path length error will be thrown
if the path to a resource file is even remotely deep within the tree.
This is largely because the target name includes the string "Windows
resource for file 'full path'", which is then expanded twice (once for
the .vcxproj itself, and once for IntDir) and added to the full path.
When combined with the tiny path limits on Windows, it is easy to exceed
path limits.
This error is largely avoided by the ninja back-end. Unlike the
vs back-end, the ninja back-end does not use target.get_id() as part of
the project file path, nor does it use target.get_id() as part of
get_target_private_dir().
Example error:
error MSB4184: The expression "[MSBuild]::NormalizePath(
C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp,
f3f7317@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\,
f3f7317@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus.
vcxproj.CopyComplete)" cannot be evaluated. Path:
C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp\f3f7317
@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\f3f7317
@@Windows resource for file
'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus.
vcxproj.CopyComplete exceeds the OS max path limit.
The fully qualified file name must be less than 260 characters.
A common pattern in Qt5 applications is to embed translations in the
executable using the qresource system. In this case, the list of
translation files is already available in the .qrc file and there's no
good reason to duplicate this info in meson.build.
Let compile_translations optionally take a qrc input, in which case it
will go straight to generating the relevant translations and
rcc-generated .cpp, and directly return the thing users actually care
about -- the .cpp for linking.
We have experimented with the module for about a year in a qemu
branch (https://wiki.qemu.org/Features/Meson), and we would like to
start moving the build system to meson. For that, keyval should have
the stability guarantees.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Add depfile support to generated targets for Qt >= 5.14.
Move warning into the module init itself, to check if the version is too
old before issuing. Also tweak the wording itself, to advise upgrading
to a suitable version of Qt5 instead of advising to wait for a Qt bug to
be fixed.
Some warnings are out of the user's control, such as the RCC QT bug,
or the GNU windres bug, or our informational warning about
auto-disabling of options when -Db_bitcode is enabled.
Such warnings should not be fatal when --fatal-meson-warnings is
passed because there's no action that the user can take to fix it. The
only purpose it serves is to prevent people who use those features
from using --fatal-meson-warnings.
Xavier Claessens
Luke Drummond
Olexa Bilaniuk
Dylan Baker
Antonin Décimo
Philip Withnall
Paolo Bonzini
Sam Thursfield
Eli Schwartz
mimi89999
Daniel Mensinger
Peter Harris
Nirbheek Chauhan
Marc-André Lureau
Nirbheek Chauhan