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)
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
If we pass a source files() object, we will look for it in the build
directory, which is wrong. If we pass a build files() object (from
configure_file()), we will find it in the build directory, and then
try to copy it on top of itself in gtkdochelper.py getting a
SameFileError.
Add a test for it, and also properly iterate custom target outputs
when adding to content files.
The fix has landed upstream, and will be in the next glib stable
release. I have verified that it fixes the problem described in #3488
and that the 'frameworks/7 gnome' test passes now.
The new --body and --header args are broken because they do not allow
the use of --output-directory to set the correct `#include "foo.h"`
line in `foo.c`. The changes in the gdbus test case show this.
Disabled till this can be fixed in glib.
Closes https://github.com/mesonbuild/meson/issues/3488
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
What is actually defined here varies wildly on different python-versions
for different platforms.
On my python2.7 on Windows len(sysconfig.get_config_vars()) returns 17,
whereas in my Ubuntu that number is 517!
Hence it is useful to be able to check which keys are available, as
well as allowing specifying a default option.
* gnome: If pkg-config is not found, assume glib is 2.0
Checking the pkg-config file to confirm tool versions is a hack, and
should eventually be replaced with checking the actual versions of the
tools.
* gnome: Actually assume glib version is 2.54 if not found
It is actually not possible to build most projects with the GNOME
module if your glib is older, particularly genmarshal and
gdbus-codegen generate unusable output without newer arguments that
were added for Meson.
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.
The `install` parameter that is present in the `permittedKwargs`
annotation is wrong. The correct parameter name, which is also
consistent with the rest of functions in the `gnome` module, is
`install_dir`.
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.
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.
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.
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>
Jon Turney
Salamandar
Mathieu Duponchelle
Xavier Claessens
Nirbheek Chauhan
Jussi Pakkanen
Havard Graff
Nirbheek Chauhan
Martin Hostettler
Iñigo Martínez
textshell
Emmanuele Bassi
Alexis Jeandet