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