Defining public API in a cross platform library is painful, especially
on Windows. Since every library have to define pretty much the same
macros, better do it in Meson.
This module is a bit of a dumping ground for code generators,
particularly ones that are important and non-trivial to wrap, either due
to multiple implementations, major command line changes, or complex
outputs (such as those that may output a directory structure).
The initially provided method is for lex. It provides a simple wrapper
that handles win_flex, reflex, flex, and generic lex.
It is unmaintained, broken (frequently for long periods of time) and not
really required for any meson functionality. Its purpose is to be used
as a one-shot tool for creating a distro package recipe, and then
deleted from your meson.build files.
Due to its fragile dependency on coredata implementation details, we
cannot assume it will reliably work, or continue to work, without
someone who is actively willing to take responsibility for it.
Even if that were to happen, this might be better off as an external
script that parses introspection data.
Closes#9764Closes#9763
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.
Discussions in #6524 have shown that there are various possible uses of the
kconfig module and even disagreements in the exact file format between
Python-based kconfiglib and the tools in Linux. Instead of trying to
reconcile them, just rename the module to something less suggestive and
leave any policy to meson.build files.
In the future it may be possible to add some kind of parsing through
keyword arguments such as bool_true, quoted_strings, etc. and possibly
creation of key-value lists too. For now, configuration_data objects
provide an easy way to access quoted strings. Note that Kconfig stores
false as "absent" so it was already necessary to write "x.has_key('abc')"
rather than the more compact "x['abc']". Therefore, having to use
configuration_data does not make things much more verbose.
This allows us to more easily have the documentation in sync with
the source code as people will have to document new features etc
right at the time where they implement it.
