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.
There are a couple new users of Meson that might be worth mentioning.
502 commits later, Libvirt and QEMU have both switched!
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
- Exceptions raised during subproject setup were ignored.
- Allow c_stdlib in native file, was already half supported.
- Eliminate usage of subproject variable name by overriding
'<lang>_stdlib' dependency name.
This attempts to clarify the usage of strings and arrays, as well as
document the boolean type that has been exposed via the project and
built-in options
This is like the project options, but for meson builtin options.
The only real differences here have to do with the differences between
meson builtin options and project options. Some meson options can be set
on a per-machine basis (build.pkg_config_path vs pkg_config_path) others
can be set on a per-subproject basis, but should inherit the parent
setting.
This allows adding a `[project options]` section to a cross or native file
that contains the options defined for a project in it's meson_option.txt
file.
* Add boost_root support to properties files
This commit implements `boost_root`, `boost_includedir`, and
`boost_librarydir` variable support to native and cross properties
files. The search order is currently environment variables, then
these variables, and finally a platform-dependent search.
* Add preliminary boost_root / boost_includedir tests
Each test contains a fake "version.hpp", as that's how boost detection is
currently being done. We look for this file relative to the root directory,
which probably shouldn't be allowed (it previously was for BOOST_LIBRARYDIR
but not for BOOST_ROOT). It also cannot help with breakage detection in
libraries, however it looks like this wasn't getting tested beforehand.
I've given the two unique version numbers that shouldn't be present in any
stock version of boost (001 and 002).
* Add return type to detect_split_root
* Return empty list when nothing found in BOOST_ROOT, rather than None
* Update boost_root tests
* Create nativefile.ini based on location of run_project_tests.py
* Add fake libraries to ensure boost_librarydir is being used
* Require all search paths for boost to be absolute
* Redo boost search ordering
To better match things like pkg-config, we now look through native/cross files,
then environment variables, then system locations for boost installations.
Path detection does not fall back from one method to the next for properties or
environment variables--if boost_root, boost_librarydir, or boost_includedir is
specified, they must be sufficient to find boost. Likewise for BOOST_ROOT and
friends. pkg-config detection is still optional falling back to system-wide
detection, for Conan.
(Also, fix a typo in test 33's nativefile)
* Correct return type for detect_roots
* Correct boost dependency search order in documentation
* Print debug information for boost library finding, to resolve CI issues
* Handle native/cross file templates in a more consistent way
All tests can now create a `nativefile.ini.in` if they need to use some
parameter that the testing framework knows about but they can't.
* Pass str--rather than PosixPath--to os.path.exists, for Python35
* Look for boost minor versions, rather than boost patch versions in test cases
* Drop fake dylib versions of boost_regex
* Prefer get_env_var to use of os.environ
* Correct error reporting for relative BOOST_ROOT paths
* Bump version this appears in. Also, change "properties file" to "machine file" as that appears to be the more common language.
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>
This header erroneously referred to the dynamic linker while the paragraph talks about
the "link editor." Change the title to account for the difference.
We don't need the legacy variable name system as for dependency()
fallbacks because meson.override_find_program() is largely used already,
so we can just rely on it.
The value for that key must be a coma separated list of dependecy names
provided by that subproject, when no variable name is needed because the
subproject uses override_dependency().
Machine files already supports `+` operator as an implementation detail,
since it's using eval(). Now make it an officially supported feature and
add a way to define constants that are used while evaluating an entry
value.
Eli Schwartz
Alex Rønne Petersen
noasakurajin
Paolo Bonzini
Xavier Claessens
Peter Harris
Michael Brockus
John Scott
Nirbheek Chauhan
Ebrahim Byagowi
Dylan Baker
Alexis Jeandet
Matthew D. Scholefield
cmcneish
Stéphane Cerveau
wb9688
Marc-André Lureau
Nathan Lanza
Michael Hirsch, Ph.D
Jussi Pakkanen
Thibault Saunier
TheQwertiest
Daniel Mensinger