| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
All paths in CFLAGS are relative to build_root, so current directory
must be there we invoking gtkdoc-scangobj.
Closes: #3379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Otherwise, when you use a File target, the value will be the full path
to the header from the build root, which is not what anyone wants.
|
|
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
|
|
|
|
* 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.
|
|
It accepts multiple XML files, not just one. For example, glib uses
it that way.
|
|
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`.
|
|
The user doesn't need to know whether or not the program was found,
especially not when it's spammed for every gnome.foo() function
|
|
|
|
|
|
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 namebase which is used as the target name, also holds part of
the file names. This used in combination generates files with wrong
names.
|
|
Also document this behaviour, test it, and fix the return value from
the module -- we create one target and return it thrice to the build
file
|
|
The `docbook` parameter used in `gdbus_codegen` should contain
the prefix string in `PREFIX-NAME.xml`. Therefore it has to be
validated as a string.
|
|
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 `gtkdoc` function in the `gnome` module is able to use generated
files as content files, but the path to these is wrong in the used
command line.
|
|
|
|
Also add a unit test that will test all codepaths for old Glib tools
versions.
Closes https://github.com/mesonbuild/meson/issues/2860
|
|
Also use that to squelch the warning for internal uses which handle the
variable missing case (just gnome at the moment)
A follow up to PR #2914
|
|
The order of -L flags in LDFLAGS is critical to the build. Any
unexpected reordering can cause undefined reference error when linking.
|
|
The reason for this change is the same as the previous commit. Although
g-ir-scanner can pick arguments from CFLAGS, CPPFLAGS, LDFLAGS
environment variables by itself, it is still better for build systems
to put them on the command line instead of relying on users to setup
the same environment.
Since g-ir-scanner doesn't provide a way to set arbitrary linker flags
on the command line, arguments in LDFLAGS that are not started with -L
are not passed.
|
|
GLib-based libraries and applications require gettext library to compile
and link. On non-GNU systems such as FreeBSD, gettext is not included in
libc and it is required to pass '-L/usr/local/lib -lintl' to the linker
to satisfy the dependency on gettext. The pkg-config file provided by
GLib already has '-lintl', but users still have to remember to put
'-L/usr/local/lib' into LDFLAGS. If we don't pass LDFLAGS to
gtkdoc-scangobj, the linker will not be able to find '-lintl' when no
dependencies of the project provides '-L/usr/local/lib'.
Since all *FLAGS are commonly used in many build systems, this commit
adds support for not only LDFLAGS but also CFLAGS and CPPFLAGS.
Fixes #1724
|
|
The gtkdoc function can also use generated targets to create
documentation. However, the dependencies over these generated files
are missing, so these must be also included in the run target.
|
|
gnome's gtkdoc function does not support content files which are
not strings. However, there are situations where files generated
by other targets might be needed.
|
|
* mesonbuild/modules/gnome.py (GnomeModule.compile_schemas): Allow the
depend_files kwarg.
* docs/markdown/Gnome-module.md: Add docs for new kwarg (and the only
other one that is permitted).
|
|
dependencies: Allow pkg-config to define variables
|
|
In a previous commit variable definition was added in pkg-config.
However, this commit was not complete.
This fixes the missing parts of that commit.
|
|
We should always prefer generated files over onces in the source tree
else if the same file also exists in the source tree we get strange
behaviour where we ignore dependencies and the project has to be
built twice to be fully up-to-date.
See: https://bugzilla.gnome.org/show_bug.cgi?id=787677
Closes https://github.com/mesonbuild/meson/issues/2686
|
|
Found by https://bugzilla.gnome.org/show_bug.cgi?id=790998
|
|
|
|
Currently, run_target does not get namespaced for each subproject,
unlike executable and others. This means that two subprojects sharing
the same run_target name cause meson to crash.
Fix this by moving the subproject namespacing logic from the BuildTarget
class to the Target class.
|
|
|
|
|
|
|
|
Fix GNOME gir generation with lists of dependency lists
|
