This mirrors the modules keyword argument that some dependencies (such
as qt and llvm) take. This allows an easier method to determine if
modules are installed.
In QEMU a single set of source files is built against many different
configurations in order to generate many executable. Each executable
includes a different but overlapping subset of the source files; some
of the files are compiled separately for each output, others are
compiled just once.
Using Makefiles, this is achieved with a complicated mechanism involving
a combination of non-recursive and recursive make; Meson can do better,
but because there are hundreds of such conditional rules, it's important
to keep meson.build files brief and easy to follow. Therefore, this
commit adds a new module to satisfy this use case while preserving
Meson's declarative nature.
Configurations are mapped to a configuration_data object, and a new
"source set" object is used to store all the rules, and then retrieve
the desired set of sources together with their dependencies.
The test case shows how extract_objects can be used to satisfy both
cases, i.e. when the object files are shared across targets and when
they have to be separate. In the real-world case, a project would use
two source set objects for the two cases and then do
"executable(..., sources: ... , objects: ...)". The next commit
adds such an example.
Because the Intel compiler behaves significantly differently on windows
than it does on Linux and MacOS I've decided it would be better to
follow the clang/clang-cl split and make id "intel-cl" on windows
(leaving "intel" alone on Linux and Mac). Since we've never supported
ICL and it hasn't worked in the past I think this is an okay change to
make.
* docs: document unrecognized escape sequence behaviour [skip ci]
Document that unrecognized escape sequence behaviour is like python, not
C.
* Don't try to decode invalid hex escape sequences
Don't try to decode escape sequences which should contain a sequence of
hex digits, but don't, throwing a python exception. These will treated
literally instead.
* Extend test case to cover invalid escape sequences
From (almost) all points of view, the Xtensa toolchain can be treated as
a regular GCC toolchain.
This patch adds very basic support so that, at least, meson does not
fail when trying to use "xt-xcc" (which makes it possible to use it
without problems).
Michael Hirsch, Ph.D