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
Otherwise we can't do the following workflow:
if not find_program('foo', required : false).found()
subproject('provides-foo')
endif
Where 'provides-foo' has a meson.override_find_program() on
a configure_file() or similar.
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.
* Never install the glib-mkenums generated C source
When using gnome.mkenums_simple() we end up installing the generated
C source file alongside the C header file, if `install_header` is set
to True. This is caused by mkenums_simple() acting as a wrapper for
mkenums() without template files; mkenums() won't be able to know if
we're generating the header or the source, and will use the presence
of `install_header` as the deciding factor as to whether the generated
file should be installed.
When generating the C source file, we should always unset the
`install_header` option to False, just like mkenums() expects.
Closes#3373
* Verify that mkenums_simple() does not install C sources
When asked to installed the generated C header file.
The added format argument for configure_file allows to specify the kind of
file that is treated. It defaults to 'meson', but can also have the 'cmake'
or 'cmake@' value to treat config.h.in files in the cmake format with #cmakedefine
statements.
Copy the algorithm used by autoconf.
It computes the upper and lower limits by starting at [-1,1] and
multiply by 2 at each iteration. This is even faster for small numbers
(the common case), for example it finds value 0 in just 2 compilations
where old algorithm would check for 1024, 512, ..., 0.
When several qrc files are given all qrc files dependencies were mixed.
Fixed non working use case:
When user try to guess build dir layout and add use a relative
path between a generated qrc file and a generated resource.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This is due to incorrect creation of dependency files:
both compilers do not escape spaces in paths.
As of version 1.21.22 of lcc, it is announced that
this bug will be corrected in future versions.
Test 132 was a template for such idea; it has been also
extended to react not only to icc, but to lcc too.
Further info (if I'm correct):
https://software.intel.com/en-us/forums/intel-c-compiler/topic/283156
Nirbheek Chauhan
Elliott Sales de Andrade
Xavier Claessens
Aleksey Filippov
Jussi Pakkanen
Martin Hostettler
makise-homura
Emmanuele Bassi
Mathieu Duponchelle
David Fort
Alexis Jeandet
behlec
Matthias Klumpp
chitranjali
Xavier Claessens
Víctor Manuel Jáquez Leal
David Seifert