Traceback (most recent call last):
File "meson.py", line 29, in <module>
sys.exit(mesonmain.main())
File "mesonbuild/mesonmain.py", line 411, in main
return run(sys.argv[1:], launcher)
File "mesonbuild/mesonmain.py", line 320, in run
return mintro.run(remaining_args)
File "mesonbuild/mintro.py", line 234, in run
list_installed(installdata)
File "mesonbuild/mintro.py", line 72, in list_installed
for path, installdir, aliases, unknown1, unknown2 in installdata.targets:
ValueError: too many values to unpack (expected 5)
When using binutils's windres, we can instruct it to invoke the preprocessor
in such a way that it writes a depfile, so that dependencies on #included
files are automatically tracked.
Not implemented for MSVC tools, so skip testing it in that case.
This new unit test will use the targets in '198 install_mode' and
confirm that every file and directory gets the expected mode, ensuring
that the setting is properly applied at install time.
When using an install_mode in install_subdir(), that should apply to the
files and not to the directory tree.
Otherwise, an install_mode not including the executable bit will make
the tree inaccessible, since directories need it to be traversed.
If the mode needs to be applied to both files and directories, then
install_subdir() is only useful to install files with the executable bit
set, which is not really that useful...
So default to just using the umask for the directories and applying
install_mode to the files only.
This can be reviewed in the future, possibly by adding a separate
install_dir_mode attribute, or perhaps adding an optional fourth field
to FileMode with the mode for directories (this is similar to how RPM
handles specifying mode of directory trees recursively added to the
package.)
For the VS backend, assertRebuiltTarget() asserts the that target is both
recompiled and relinked. This isn't correct for test_rc_depends_files, as
changing the rc script's dependencies only causes the executable to be
relinked, and not to also have it's source recompiled.
assertRebuiltTarget already gets this right for the ninja backend.
Expose depend_files: from the custom_target this creates.
This is the change suggested in #2815, with tests and documentation added.
Fixes#2789 (duplicate #2830)
Instead of using fragile guessing to figure out how to invoke meson,
set the value when meson is run. Also rework how we pass of
meson_script_launcher to regenchecker.py -- it wasn't even being used
With this change, we only need to guess the meson path when running
the tests, and in that case:
1. If MESON_EXE is set in the env, we know how to run meson
for project tests.
2. MESON_EXE is not set, which means we run the configure in-process
for project tests and need to guess what meson to run, so either
- meson.py is found next to run_tests.py, or
- meson, meson.py, or meson.exe is in PATH
Otherwise, you can invoke meson in the following ways:
1. meson is installed, and mesonbuild is available in PYTHONPATH:
- meson, meson.py, meson.exe from PATH
- python3 -m mesonbuild.mesonmain
- python3 /path/to/meson.py
- meson is a shell wrapper to meson.real
2. meson is not installed, and is run from git:
- Absolute path to meson.py
- Relative path to meson.py
- Symlink to meson.py
All these are tested in test_meson_commands.py, except meson.exe since
that involves building the meson msi and installing it.
There are cases when it is useful to wrap the main meson executable with
a script that sets up environment variables, passes --cross-file, etc.
For example, in a Yocto SDK, we need to point to the right meson.cross
so that everything "just works", and we need to alter CC, CXX, etc. In
such cases, it can happen that the "meson" found in the path is actually
a wrapper script that invokes the real meson, which may be in another
location (e.g. "meson.real" or similar).
Currently, in such a situation, meson gets confused because it tries to
invoke itself using the "meson" executable (which points to the wrapper
script) instead of the actual meson (which may be called "meson.real" or
similar). In fact, the wrapper script is not necessarily even Python, so
the whole thing fails.
Fix this by using Python imports to directly find mesonmain.py instead
of trying to detect it heuristically. In addition to fixing the wrapper
issue, this should make the detection logic much more robust.
This will copy the file to the build directory without trying to read
it or substitute values into it.
Also do this optimization if the configuration_data() object passed to
the `configuration:` kwarg is empty, and print a warning about it.
See also: https://github.com/mesonbuild/meson/issues/1542
The fallback might be not used not only because it couldn't be found, but
also because something went wrong trying to use it.
Also, update a test which relies on the specific text
We were setting it to a file list that would always be wrong, and
always out of date since it would never exist.
However, the output list is not predictable. It usually has a 1-1
relationship with the input XML files, but it may not.
This must be fixed later with API for users to provide the output
names.
See: https://github.com/mesonbuild/meson/pull/3539
pypy installations don't usuallyy ship with pkg-config files,
we thus need to replicate what their version of distutils does.
In addition, we also try our best to build against other
pythons that do not have pkg-config files.
Libraries that have been linked with link_whole: are internal
implementation details and should never be exposed to the outside
world in either Libs: or Libs.private:
Closes https://github.com/mesonbuild/meson/issues/3509
Unit test was asserting that
"meson --bindir=foo --bindir=bar" must succeed and
"meson configure --bindir=foo --bindir=bar" must fail.
There should be no difference between those 2 command lines.
In this case it's fine to have it twice because there is no ambiguity,
second overrides the first, that's done by python's argparse.
The fix for Requires generation in #3406 missed a second code path with the same
problem.
Passing a pkgconfig dependency to requires would produce Q, t, 5, C, o,r, e'
instead of 'Qt5Core'.
This was introduced in 8efd940.
This test copies a src tree using umask of 002, then runs the build and
install under umask 027. It ensures that the default install_umask of
022 is still applied to all files and directories in the install tree.
This way they override all other arguments. This matches the order of
link arguments too.
Note that this means -I flags will come in afterwards and not override
anything else, but this is correct since that's how toolchain paths
work normally too -- they are searched last.
Closes https://github.com/mesonbuild/meson/issues/3089
The linkers currently do not support ninja compatible output of
dependencies used while linking. Try to guess which files will be used
while linking in python code and generate conservative dependencies to
ensure changes in linked libraries are detected.
This generates dependencies on the best match for static and shared
linking, but this should not be a problem, except for spurious
rebuilding when only one of them changes, which should not be a problem.
Also makes sure to ignore any libraries generated inside the build, to
keep the optimisation working where changes in a shared library only
cause relink if the symbols have changed as well.
Previously pkg-config files generated by the pkgconfig modules for static libraries
with dependencies could only be used in a dependencies with `static: true`.
This was caused by the dependencies only appearing in Libs.private even
if they are needed in the default linking mode. But a user of a
dependency should not have to know if the default linking mode is static
or dynamic; A dependency('somelib') call should always pull in all
needed pieces into the build.
Now for meson build static libraries passed via `libraries` to the generate
method automatically promote dependencies to public.
Fixes the bug with flat layout and identical target names in subprojects.
Without this change directories are not created with subproject prefix
and they can collide.
Remove dead makedirs code in Backend.__init__(), during initialization
of backend build.targets is empty. Create output directories in
Vs2010Backend.generate_projects() instead.
Also use double blank line in run_unittests.py according to
https://www.python.org/dev/peps/pep-0008/#blank-lines.
Sometimes it is needed to run the current compiler with specific options
not to compile a file but rather to obtain additional info. For example,
GCC has several -print-* options to query it about the paths to
different libraries and development files. One use case is to get the
location of development files for GCC plugins, which is not easily
obtainable by other means:
gcc -print-file-name=plugin
For this purpose, it would be convenient if the compiler object returned
by meson.get_compiler(lang) could be used in run_command() directly.
This commit implements it.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Enable linux-like unit tests on all posix-like platforms, not just linux,
skipping tests where appropriate. This enables these tests for OSX and
Cygwin in CI.
* Allow in-process (as well as out of process) tests to be skipped by
returning MESON_SKIP_TEST
This is needed to allow test_old_gnome_module_codepaths to be skipped when
'test cases/frameworks/7 gnome' is missing it's pre-prequisites
* Skip PIC tests on platforms where it's irrelevant
* Apple Clang reports the XCode version number, not the LLVM version number,
so the check for stdc(|++)17 needs adjusting
* Skip tests that only pertain to ELF or RPATH mechanics when irrelevant
* Skip tests that require valac if missing
* Skip asan test on Cygwin
$ flake8 | grep -E 'F841'
./run_unittests.py:1987:13: F841 local variable 'objc' is assigned to but never used
./run_unittests.py:1988:13: F841 local variable 'objcpp' is assigned to but never used
./mesonbuild/minit.py:272:5: F841 local variable 'uppercase_token' is assigned to but never used
./mesonbuild/minit.py:307:5: F841 local variable 'uppercase_token' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:36:9: F841 local variable 'result' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:78:9: F841 local variable 'up_target' is assigned to but never used
./mesonbuild/modules/unstable_icestorm.py:81:9: F841 local variable 'time_target' is assigned to but never used
./msi/createmsi.py:226:17: F841 local variable 'file_source' is assigned to but never used
$ flake8 | grep -E '(E123|E127|E128)'
./run_unittests.py:1358:37: E127 continuation line over-indented for visual indent
./run_unittests.py:1360:37: E127 continuation line over-indented for visual indent
./mesonbuild/minit.py:311:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:312:66: E128 continuation line under-indented for visual indent
./mesonbuild/minit.py:313:66: E128 continuation line under-indented for visual indent
./mesonbuild/compilers/cpp.py:115:63: E127 continuation line over-indented for visual indent
./msi/createmsi.py:156:13: E123 closing bracket does not match indentation of opening bracket's line
./msi/createmsi.py:188:13: E123 closing bracket does not match indentation of opening bracket's line
Modern gcovr includes html generation support so if lcov and
genhtml are not available fallback to gcovr.
Kept lcov and genhtml as default so to not surprise existing
users of coverage-html with the different output of gcovr.
gcovr added html support in 3.0 but as there already is a test
for 3.1 because of the changes to -r/--rootdir I opted to only
allow html generation for >= 3.1 to keep things simple.
This can help future generations avoid mistakes like this:
edb1c66239
To avoid breaking builds, this is currently just an error. After
sufficient time has passed this can hopefully become a hard error,
similarly to the already-existing `permittedKwargs` warnings.
There's no reason not to also look in these places on Cygwin or OSX. Don't
do this on Windows, as these paths aren't meaningful there.
Move test_cross_file_system_paths from LinuxlikeTests to AllPlatformTests.
A hard error makes this feature useless in most cases since a static
library usually won't be found for every library, particularly system
libraries like -lm. Instead, warn so the user can provide the static
library if they wish.
This feature will be expanded and made more extensible and more usable
in the future.
Closes https://github.com/mesonbuild/meson/issues/2785
We missed one particular edge-case in #2413: when the generated vala
file is inside --basedir, the path is not just the basename.c
Since this case can never happen in a project test, this includes a unit
test for the same.
Closes https://github.com/mesonbuild/meson/issues/815
Examples:
meson.build:2:0: ERROR: Dependency is both required and not-found
meson.build:4: WARNING: Keyword argument "link_with" defined multiple times.
These are already matched by the default compilation-error-regexp-alist in
emacs.
Also:
Don't start 'red' markup until after the \n before an error
Unabsorb full-stop at end of warning with location from mlog.warning()
Update warning_location test
Currently only not found deps implicitly pulled from a Library object
are ignored. We should also ignore not found deps passed directly to
generate() method.
This makes the unit testing more complicated because libfoo pkgconfig
dependency cannot be found when generated from the within the same
meson.build.
This already reports the location (in a slightly different format), but
using mlog.warning() will make it easier if we want to change the location
format in future.
If a dep is not found on the system and a fallback is specified, we
have two cases:
1. Look for the dependency in a pre-initialized subproject
2. Initialize the subproject and look for the dependency
Both these require version comparing, ensuring the fetched variable
is a dependency, and printing a success message, erroring out, etc.
Now we share the relevant code instead of duplicating it. It already
diverged, so this is a good thing.
As a side-effect, we now log fallback dependencies in the same format
as system dependencies:
Dependency libva found: YES
Dependency libva found: YES (cached)
Dependency glib-2.0 from subproject subprojects/glib found: YES
Dependency glib-2.0 from subproject subprojects/glib found: YES (cached)
I have a tendency to typo things. Humans in general are bad at spotting
spelling mistakes, computers are not. This patches prints the bad
options and provides the generic meson "This will be a hard error
someday" message.
Using NotImplementedError throws an ugly traceback to the user which
does not print the line number and other information making it
impossible to figure out what's causing it.
Also override it for internal dependencies because self.name is "null"
for them.
The .a library was being built with `ar` which is not the right
static archiver, it's supposed to be something like
x86_64-w64-mingw32-ar or whatever the target-triple is.
Try using the built-in static linker detection instead of doing it
manually.
One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
This exposes the already existing UserStringArrayOption class through
the meson_options.txt. The intention is to provide a way for projects to
take list/array type arguments and validate that all of the elements in
that array are valid without using complex looping constructrs.
This is enough to fix things.
Note that build_shared_lib doesn't use the implib name for mingw or cygwin
gcc, only msvc, so I'm not quite sure how this is working, I guess we are
using the gcc facility to link directly with a dll...
Also, make BasePlatformTests.tearDown() tolerate wipe() already having been
called, rather than AllPlatformTests.test_prefix_dependent_defaults() having
to avoid wipe() on the final iteration.
Precompiled headers should generally be compiled with the same flags as
the sources that will include the header. Some deviations are safe,
however, most will cause the compiler to reject the precompiled header
or possibly lead to compiler crashes.
In addition to filtering libs out while generating the command-line, we
must also filter them out in find_library() otherwise these libs will be
detected as "found" on Windows with MSVC.
Closes https://github.com/mesonbuild/meson/issues/1509
While adding link args for external deps, sometimes different
libraries come from different prefixes, and an older version of the
same library might be present in other prefixes and we don't want to
accidentally pick that up.
For example:
/usr/local/lib/libglib-2.0.so
/usr/local/lib/pkgconfig/glib-2.0.pc
/usr/local/lib/libz.so
/usr/local/lib/pkgconfig/zlib.pc
/home/mesonuser/.local/lib/libglib-2.0.so
/home/mesonuser/.local/lib/pkgconfig/glib-2.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig/:/usr/local/lib/pkgconfig/"
If a target uses `dependencies : [glib_dep, zlib_dep]`, it will end up
using /usr/local/lib/libglib-2.0.so instead of
/home/mesonuser/.local/lib/libglib-2.0.so despite using the pkg-config
file in /home/mesonuser/.local/lib/pkgconfig because we reorder the -L
flag and separate it from the -l flag.
With this change, external link arguments will be added to the
compiler list without de-dup or reordering.
Closes https://github.com/mesonbuild/meson/issues/1718
Boost tests are disabled on Windows for now because the detection
is actually completely broken. Once that's fixed (after the release)
we can enable it again.
It is not feasible to test all failure modes by creating projects in
`test cases/failing` that would be an explosion of files, and that
mechanism is too coarse anyway. We have no way to ensure that the
expected error is being raised.
See FailureTests.test_dependency for an example.
This is more reliable, and more accurate. For instance, this means
arguments in commands aren't surrounded by `'` on Linux unless that
is actually needed by that specific argument.
There is no equivalent helper for Windows, so we keep the old
behaviour for that.
Now we aggressively de-dup the list of libraries used while linking,
and when linking with GNU ld we have to enclose all static libraries
with -Wl,--start-group and -Wl,--end-group to force the linker to
resolve all symbols recursively. This is needed when static libraries
have circular deps on each other (see included test).
The --start/end-group change is also needed for circular dependencies
between static libraries because we no longer recursively list out all
library dependencies.
The size of build.ninja for GStreamer is now down to 6.1M from 20M,
and yields a net reduction in configuration time of 10%
This is useful when build_machine appears to be compatible with
host_machine, but actually isn't. For example when:
- build_machine is macOS and host_machine is the iOS Simulator
- the build_machine's libc is glibc but the host_machine libc is uClibc
- code relies on kernel features not available on the build_machine
Usage:
pkgconfig.generate(
...
description : 'A library with custom variables.',
variables : ['foo=bar', 'datadir=${prefix}/data']
)
The variables 'prefix', 'libdir' and 'includedir' are reserved, meson will
fail with an error message.
Variables can reference each other with the pkgconfig notation, e.g.
variables : ['datadir=${prefix}/data',
'otherdatadir=${datadir}/other']
meson does not check this for correctness or that the referenced variable
exists, we merely keep the same order as specified.
This actually caught a cached-dependency related bug for me that the
test-time regen did not. I also increased the ninja wait time to
1 second because that's actually how long you need to sleep to be
guaranteed that a change will be detected.
Must poke upstream about https://github.com/ninja-build/ninja/issues/371
And use generic build/clean/test/install commands in the unit tests,
just like project tests. This sets the groundwork for running the unit
tests with all backends.
configure a detection method, for those types of dependencies that have
more than one means of detection.
The default detection methods are unchanged if 'method' is not
specified, and all dependencies support the method 'auto', which is the
same as not specifying a method.
The dependencies which do support multiple detection methods
additionally support other values, depending on the dependency.
Now as long as you have a C compiler available in the project, it will
be used to compile assembly even if the target contains a C++ compiler
and even if the target contains only assembly and C++ sources.
Earlier, the order in which sources appeared in a target would decide
which compiler would be used.
However, if the project only provides a C++ compiler, that will be
used for compiling assembly sources.
If this breaks your use-case, please tell us.
Includes a test that ensures that all of the above is adhered to.
Special wrap modes:
nofallback: Don't download wraps for dependency() fallbacks
nodownload: Don't download wraps for all subproject() calls
Subprojects are used for two purposes:
1. To download and build dependencies by using .wrap files if they
are not provided by the system. This is usually expressed via
dependency(..., fallback: ...).
2. To download and build 'copylibs' which are meant to be used by
copying into your project. This is always done with an explicit
subproject() call.
--wrap-mode=nofallback will never do (1)
--wrap-mode=nodownload will do neither (1) nor (2)
If you are building from a release tarball, you should be able to
safely use 'nodownload' since upstream is expected to ship all
required sources with the tarball.
If you are building from a git repository, you will want to use
'nofallback' so that any 'copylib' wraps will be download as
subprojects.
Note that these options do not affect subprojects that are git
submodules since those are only usable in git repositories, and you
almost always want to download them.
We were adding them to the CompilerArgs instance in the order in which
they are specified, which is wrong because later dependencies would
override previous ones. Add them in the reverse order instead.
Closes https://github.com/mesonbuild/meson/issues/1495
Because we are using check_output, if the command fails no output will
be printed at all. So, we use subprocess.run instead.
Also, on configure failures, print the meson-log.txt instead of stdout.
If you pass options, the last element in the array won't be the
compiler basename, so just check if the basename is in the exelist
somewhere.
Includes a test.
https://github.com/mesonbuild/meson/pull/1406 had an incomplete fix
for this. The test case caught it.
Note: this still doesn't test that setting it in the cross-info works,
but it's the same codepath as via the environment so it should be ok.
https://github.com/mesonbuild/meson/pull/1406 had an incomplete fix
for this. The test case caught it.
Note: this still doesn't test that setting it in the cross-info works,
but it's the same codepath as via the environment so it should be ok.
Factor it out into a function in mesonlib.py. This will allow us to
reuse it for generators and for configure_file(). The latter doesn't
implement this at all right now.
Also includes unit tests.
And actually test that prog.path() works. The earlier test was just
running the command without checking if it succeeded.
Also make everything use prog.get_command() or get_path() instead of
accessing the internal member prog.fullpath directly.
We also need to check whether the program found in PATH can be executed
directly by Windows or if we need to figure out what the interpreter is
and add it to the list.
Also add `msc` to the list of extensions that can be executed natively
Includes a project test and a unit test for this and all expected
behaviours on Windows.
On macOS, the temporary directory is inside /var/folders, but /var is
a symlink to /private/var, and for some reason that messes up path
traversal when you're inside the temporary directory and the source
directory is never found, and ninja runs in a loop trying to
regenerate files that can never be regenerated.
Otherwise if the list of sources changes on reconfigure after building,
the static library will contain both the old and new objects.
Closes https://github.com/mesonbuild/meson/issues/1355
os.path.commonpath (and our implementation of it) both always return the
path using the native operating system path separator, so we can't just
directly compare it since the prefix could be specified in '/', and
commonpath would use '\' on Windows.
Also add a unit test for this.
os.path.commonpath was added in Python 3.5, so just write our own for
now. pathlib was added in Python 3.4, so this should be ok. We need to
use that instead of doing str.split() etc because Windows path handling
has a lot of exceptions and pathlib handles all that for us.
Also adds a unit test for this.
At the same time, also fix the order in which compile arguments are
added. Detailed comments have been added concerning the priority and
order of the arguments.
Also adds a unit test and an integration test for the same.
Also add a test() that can be run on all platforms.
Currently unit tests are only run on Linux, so this was only testing the
Ninja backend. This change reveals that build-by-default was broken with
the Visual Studio backend.
The purpose of this class is to make it possible to sanely generate
compiler command-lines by ensuring that new arguments appended or added
to a list of arguments properly override previous arguments.
For instance:
>>> a = CompilerArgs(['-Lfoo', '-DBAR'])
>>> a += ['-Lgah', '-DTAZ']
>>> print(a)
['-Lgah', '-Lfoo', '-DBAR', '-DTAZ']
Arguments will be de-duped if it is safe to do so. Currently, this is
only done for -I and -L arguments (previous occurances are removed when
a new one is added) and arguments that once added cannot be overriden
such as -pipe are removed completely.
With the 'install_mode' kwarg, you can now specify the file and
directory permissions and the owner and the group to be used while
installing. You can pass either:
* A single string specifying just the permissions
* A list of strings with:
- The first argument a string of permissions
- The second argument a string specifying the owner or
an int specifying the uid
- The third argument a string specifying the group or
an int specifying the gid
Specifying `false` as any of the arguments skips setting that one.
The format of the permissions kwarg is the same as the symbolic
notation used by ls -l with the first character that specifies 'd',
'-', 'c', etc for the file type omitted since that is always obvious
from the context.
Includes unit tests for the same. Sadly these only run on Linux right
now, but we want them to run on all platforms. We do set the mode in the
integration tests for all platforms but we don't check if they were
actually set correctly.
With the exception of things like sysconfdir (/etc), every other
installation directory option must be inside the prefix.
Also move the prefix checks to coredata.py since prefix can also be set
from inside project() with default_options and via mesonconf. Earlier
you could set prefix to a relative path that way.
This also allows us to return consistent values for get_option('xxxdir')
regardless of whether relative paths are passed or absolute paths are
passed while setting options on the command-line, via mesonconf, or via
default_options in project(). Now the returned path will *always* be
relative to the prefix.
Includes a unit test for this, and a failing test.
Closes#1299
Compiler versions 15.0 and later actually ignore invalid values for the
-std= option unless `-diag-error 10159` is passed, so we need to put
that in the unit test.
I have tested this with versions 14.0.3, 15.0.6, 16.0.4, and 17.0.1.
Would be great if someone could test with 13.x.y
'-w' in c_command will check for it as a substring, which will also
match '-wd', etc. So match it with quotes. This won't give us false
positives, but might give us false negatives in case the argument is not
quoted, but that's better behaviour for a test.
The alternative is to split the string command, but the command does not
necessarily obey shell quoting rules, so we cannot reliably use
shlex.split().
This approach is locale-independent and more correct. For instance, this
will work with UTF-16 while the previous approach with binary comparison
would not.
This also removes the need for doing an explicit decode to utf-8 which
is lossy and can fail by yielding no output at all.
We want compiler check arguments (-O0, -fpermissive, etc) to override
all other arguments, and we want extra_args passed in by the build file
to always override everything.
To do this properly, we must split include arguments out, append them
first, append all other arguments as usual, and then append the rest.
As part of this, we also add the compiler check flags to the
cc.compiles() and cc.links() helper functions since they also most
likely need them.
Also includes a unit test for all this.
Nirbheek Chauhan