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.
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.
FFY00