Re: [gentoo-dev] [RFC] New eclass: mate

[NP-Hardass]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/11/2016 01:09 AM, NP-Hardass wrote:
> Greetings all,
>
> As all potential new eclasses are supposed to be discussed here, I
> thought I'd file a message and see if anyone had anything to
> contribute on the matter.
>
> I'm in the midst of a major version bump for the entirety of the
> MATE desktop environment, consisting of 40-50 packages.  There is a
> huge amount of repetition in my ebuilds, and a lot of things are
> formulaic (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare,
> etc).  As such, I think that moving all of that to an eclass would
> greatly simplify my life and my ebuilds, so I thought I'd look into
> creating an eclass.
>
> Any opinions either way?   Thanks in advance.
>
>
>

A little background, MATE is a fork of GNOME, so there are many things
in common, however, the two aren't always in sync.  As such, there is
often code reuse, but not always.  For example, GNOME has deprecated
GNOME_DEBUG macros whereas MATE has not done so yet.

Attached are two eclasses mate-desktop.org.eclass and mate.eclass.

mate-desktop.org.eclass mimics the gnome.org eclass.  It defines a
couple of useful variables, as well as sets SRC_URI or EGIT_REPO_URI
for a live ebuild.

mate.eclass is supposed to parallel gnome2.eclass.  A couple of notes:
mate-desktop.org.eclass is necessary to override all of the defaults
in gnome.org.eclass which are not applicable to MATE. The src_prepare
function is borrowed from autotools-utils.  With EAPI 6, if any user
is capable of modifying the build system via eapply_user, I'd like to
be able to detect and regenerate the build system accordingly.
Additionally, upstream does not supply Makefiles or configure scripts
for live ebuilds, so I always have to run eautoreconf in those cases.
Stubs: Well, you will probably notice that I have stubs to the gnome2
remaining functions.  This was done for several reasons.  1) in the
event that the gnome2 eclass goes in a different direction than MATE,
it's easy to switch our own implementation, and 2) if I don't and I
have reference to the gnome2 eclass, I have to explicitly inherit it
in all ebuilds, which somewhat defeats the point the indirection
gained by having the mate eclass.   I'd have to inherit gnome2 mate
mate-desktop.org in every ebuild to ensure that everything is
inherited properly.  It's a little bit messy, but still doable.  But
for the previous reason, built in independence from the gnome eclass
if needed, it seems much easier to me to stub out gnome2 in the meantime
.

- -- 
NP-Hardass
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXDD34AAoJEBzZQR2yrxj7ELkQAJK78s2tNt67XR7fgIYWZkTa
a52MsFdW5e14yqKZAmKZqIde3zRo65BAoa15BVscM2o9iH1CtJolbrq0i603OBej
RGt5RkgOqmUYg8lU/z1fyX7PLzm3ukTBSNQ0Y5m5jofo2sbg4WMFiaaQkmvChnQd
TA5dI+nMzz8gfQJvXoorj+JZziOikH4i8lsge2QKP7IUDe16fjUO8VM8J+5v4uk+
XXeIPFq3PXoHeGW9jLo9jibapntDlPOStoalY5dRIkIZSpe124TfVhCSOMeuWtRB
VzvvaW+D2MFL9NU2WcsQtU8H71CY/bZl3qPiA9n6OcFowIyVXBP9W7lhpcBmWbYx
HIsI8UEXriuMJPhiZ/mzkEKaXohElcvbolvQigejGCxzJVQ1fxpoHINXaN/KCEQ8
fxsKeLCM/toPuFcqjru1znZb05cLm1UAcN15YK3ldrcJNGY9tPxHj09dt74eIWor
49HZeFSftef637vFA+3NEN9aVVRyd9O9Fc+wK8FI7ki3O2br4SoOw122NUfjFWoB
4xguWOJjspcbxobzK7nzrKhTYLDhh+oymTj4TLmmzvTo3zgBgYhbVJNP5HoycfPB
nZBzYZIht0bl/BbdGvdOyDVacLG+X7QlWKcx/bUmcrv3rih59D8XrtzlVhOavvhW
RZ4Wo+feNwXrLN9aOfcL
=GGgO
-----END PGP SIGNATURE-----