dev-util/glib-utils: Build time utilities for glib using projects
authorMart Raudsepp <leio@gentoo.org>
Sat, 18 Aug 2018 01:24:25 +0000 (04:24 +0300)
committerMart Raudsepp <leio@gentoo.org>
Mon, 20 Aug 2018 06:10:58 +0000 (09:10 +0300)
commit719d166fdbc46d1f06198f8c13f0e514349581a5
treef2f8b2a889dcd024f181b5c3b221da3b5df4ef81
parent8a9f1f25ccd3822fe260a048eee50947fd9b113b
dev-util/glib-utils: Build time utilities for glib using projects

This package will house a set of utilities split out of dev-libs/glib,
primarily to avoid a runtime dependency on python in dev-libs/glib
itself, for e.g. embedded system purposes. Once the consumers of
these utilities build depend on this and the forced dep in glib
can be dropped, that is.

Initially glib-genmarshal, glib-mkenums and gtester-report are part
of this package, as these require python at runtime.
gdbus-codegen is likely to remain a separate package, as it installs
a bigger python module.
glib-compile-resources might at some point be moved here, as then
we can express its potential runtime dependencies of libxml2:2 and
gdk-pixbuf:2 here, but this is undecided as of yet, and won't happen
before meson is used for building glib.

This commit adds a transitional glib-utils-2.52.3 with stable
keywords for migration purposes. It just pulls in glib itself, which
at that version provides the tools itself. This allows other
packages to start build depending on dev-util/glib-utils right away,
as there will be no wait for stable keywords.

If your package calls glib-genmarshal or glib-mkenums, then please add
a build dependency on dev-util/glib-utils. With meson a good hint of
such usage is the occurrence of "genmarshal" or "mkenums" in any
meson.build file; usually with "gnome." in front, but it depends under
what name the meson gnome module is imported as ("gnome" is the
convention out there).
With autotools a good hint is a direct call to either utility in any
Makefile.am file, however with autotools generated marshallers or
enums are often shipped in release tarballs without a need to
regenerate them, in which case the dependency may be unnecessary.

gtester-report is a deprecated utility to generate HTML reports out
of gtester output. Some packages test phases have a dependency on it,
or a build time check, even if not actually used in relevant make
targets. In such a case it might be more appropriate to shortcut
the check with something like "GTESTER_REPORT=$(type -P true)" instead
of depending on this package, as no-one is going to be looking at those
HTML reports. But sometimes it might be used in default check targets,
which would have to be patched out; so just depending on glib-utils is
a possibility until such a time (or if not worth the effort).

Package-Manager: Portage-2.3.47, Repoman-2.3.10
dev-util/glib-utils/glib-utils-2.52.3.ebuild [new file with mode: 0644]
dev-util/glib-utils/metadata.xml [new file with mode: 0644]