Fix the circular dependency by moving the generated
headers to gdk/version/, and build that directory
first.
Misc other fixes, such as putting the custom targets
as sources, not depedencies, and using the correct
major version in the generator script.
Let's poach the same script used by GLib to avoid having to add all the
version macros by hand every time we increment the GTK version.
This is a work in progress:
- need to rename the GLIB_STATIC_COMPILATION check
- circular dependency: libgtkcss depends on gdkversionmacros.h, but libgdk
depends on libgtkcss
The script assumes that the git program is in the PATH which may not be always
the case, so if git was not found, fallback to the former behavior of making
VCS_TAG an empty string if the profile option was not set to 'devel'.
Also fix the call to the script so that we do indeed call GIT on the source GIT
repo so that we can get the right short SHA1 sum.
Re-organize the code a bit in the process, so that things seem cleaner.
The CI pipeline does not do a full clone, so we cannot use `git
rev-parse` to get the short SHA checksum for the current commit.
Of course, since nothing's ever easy, we cannot use vcs_tag() with a
custom command, so we need to generate our out `demo_conf.h` header
straight from a script.
When I added the sassc option, I failed to ensure that
the theme css is included in the tarballs. This is required
to make tarball builds with -Dsassc=disabled work.
The pkg-config variables have been added in GLib 2.62.0. Let's fallback
to default names for these tools in such case (`pkg-config` still
returns a 0 return value, but with empty output for absent variables).
Some distributions are renaming Glib/GIO utilities for multi-arch
reasons so pkg-config variables have been added to find the correct name
of a tool. GTK+ should use these variables instead of searching in PATH.
See glib#1796.
While *some* systems alias python to python3 nowdays, this is
not true for eveything. Especially systems that can potentially
offer both python2 and python3.
According to both PEP 394 and PEP 441 its recommended to always
add the 3 in the shebang.
The existing post-install shell script will most likely not work on
Visual Studio builds as there is normally no shell interpreter installed
on the system where the build is done, but the build is normally done in
a standard Windows cmd.exe console.
Instead, use a Python script so that it will work on the platforms that
Python supports.
GIO has this facility, so we should use it.
At the same time, make sure the immodules directory
exists, even if we don't install any modules there
outselves.
Add an extension point called gtk-im-module, which requires
the type GtkIMContext. Simplify the loading by using GIO
infrastructure. Drop the locale filtering for now, I don't
think it is really necessary nowadays.
Convert existing platform modules to gio modules.
Sill to do: Drop the conditional build machinery.
Either always include them, or never.
Before running gtk-query-immodules, the cache output directory may not
actually exist. Make sure it does before we try to write into it.
https://bugzilla.gnome.org/show_bug.cgi?id=793182
Signed-off-by: Daniel Stone <daniels@collabora.com>
When building GTK+ straight from the repository without any assistance
from packaging tools, we need to trigger system-wide updates, like the
icon theme cache update, or the schema compilation.
