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.
This caching is only for a single run, so it doesn't help reconfigure.
However, it is useful for subproject setups where different subprojects
will run the same compiler checks.
The cache is also per compiler instance and is not used for functions
that want to read or run the outputted object file or binary.
For gst-build, this halves the number of compiler checks that are run
and reduces configuration time by 20%.
when flattening the chained dependencies of an object, we don't need to
create any new internal dependencies if all the fields to be added to it
are empty.
For projects with a lot of libraries and dependency objects this can lead
to noticeable performance improvements.
fixup
When getting dependencies, we don't need to get the same dependencies and
dependency chains multiple times. If library a depends on x, y and z, and
library b depends on a, then we should not have to iterate through x, y and
z multiple times. Pruning at the stage of scanning the dependencies leads
to significant time savings when running meson
This halves the configure time in gst-build, the aggregate of all
GStreamer repositories.
We can't do this to Popen_safe because we can't be sure that other
programs have no side-effects and will always return the same output
for the same arguments and environment.
The `ct` variable used in the ModuleReturnValue is created only for
versions earlier than 2.55.2. However, in newer versions that
variable does not exist.
Implementing set_value() in the base class simplifies the code and
ensure validation is always consistent.
This fix UserIntegerOption.validate_value() not checking min/max value,
and UserArrayOption.validate_value() raising exception because it does
not pass a value for user_input argument of validate() method.
Fixes "warning: --output and -o have no effect when -C or --ccode is set"
get_always_args() adds -C which is already disabling the direct compilation
ability of valac for which -o is used.
The development version of `glib` (2.55.2) has acquired support for
generating gdbus header and source code files separately. This
allows dependencies to be more fine grained on those targets
depending only on the header.
* 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.
This can be useful to make sure that a project builds when
its fallbacks are used on systems where external dependencies
satisfy the version requirements, or to easily hack on the sources
of a dependency for which a fallback exists.
Since relative path in qrc files are always relative to qrc file
itself then we just need to check that normpath(qrc file + resource)
doesn't start with build dir path, this would mean that the resource is
generated.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
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>
It is weird and inconsistent to have different pc file depending on
default_library value when using library() or build_target(). We should
skip dependencies only when user explicitly want shared library only.
Jussi Pakkanen
Martin Hostettler
Alberto Sartori
Nirbheek Chauhan
textshell
Robin
Jon Turney
Daniel Schulte
Bruce Richardson
makise-homura
Iñigo Martínez
Xavier Claessens
Andrei Alexeyev
Rico Tzschichholz
Emmanuele Bassi
Mathieu Duponchelle
David Fort
Paul I
Christoph Behle
Alexis Jeandet
Sébastien Wilmet