the fact that foo and bar are not directories makes Apple's ld upset, and with
fatal warnings it dies on this test. Using real directories makes it happy.
'if_true' sources should be built with their dependencies, as
illustrated by test case change.
Ideally, I think we would want only the files with the dependencies to
be built with the flags, but that would probably change the way
sourceset are used.
* PGI C++ PCH enable
PGI compilers support precompiled headers for C++ only.
The common/13 pch test passes if run manually with no spaces in the build path.
However, since Meson run_project_tests.py makes temporary build directories
with spaces in each tests, PGI --pch_dir can't handle this and fails.
So we skip the test for PGI despite it working for usual case with no-spaces
in build dir.
Note: it's fine to have spaces in full path for sourcedir, just no spaces in
relative path to builddir.
* doc
The Windows CI runs with codepage 1252, which is basically ISO-8859-1 and does not
have a mapping for character U+0151 (ő). It is currently passing because of a
happy accident, as the generator command line is emitted in UTF-8 anyway
(starting at commit 6089631a, "Open build files with utf-8", 2018-04-17, which
however lacks documentation or history) and file.py treats it as two
single-byte characters.
When going through meson_exe, however, Windows passes a genuine Unicode
character via CreateProcessW and file.py fails to decode it, so we need to
pass errors='replace' when opening the output file.
On Windows, the test is then fixed. On POSIX systems it is _still_ passing as
a happy accident because (according to the current locale) the output file
contains two single-byte characters rather than the single Unicode character
"ő"; in fact, if one modifies the ninja backend to use force_serialize=True,
meson_exe fails to build the command line for file.py and stops with a
UnicodeEncodeError.
This further simplifies behavior to match the "build vs host" decision
we did with `c_args` vs `build_c_args`. The rules are now simply:
- `native: true` affects `native: true` targets
- `native: false` affects `native: false` targets
- No native flag is the same as `native: false`
I like this because you don't even have to know what "build" and "host"
mean to understand how it works, and it doesn't depend on whether the
overall build is cross or not.
Fixes#4933
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.
* 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
`-Dtest_harmless_but_useless_link_arg` won't actually do anything
without anything to preprocess, but least it is valid for GCC and MSVC,
and won't be caused by anything else.
Currently if a dependency is added to declare_dependency, and the top
dependency doesn't have an attribute that the subdependency does, it
wont be propagated by subdependency.