Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] rfc: eclass issues
Date: Mon, 18 Aug 2014 13:18:35
In Reply to: Re: [gentoo-dev] rfc: eclass issues by hasufell
1 On Mon, Aug 18, 2014 at 8:12 AM, hasufell <hasufell@g.o> wrote:
2 >
3 > I think the first thing to do and which already happened with e.g.
4 > qmake-utils.eclass is to make a very strong distinction between utility
5 > eclasses and those that export phase functions.
6 >
8 Discussion on IRC the other day was moving in this direction as well.
9 My email was almost contemplating a technical way of doing this, but
10 I'm not entirely convinced that we could ever make a clean distinction
11 between these. Certainly preventing automatic multiple inheritance
12 would help though.
14 I think that we should take a utility-vs-"wraparound" approach to
15 eclass design. Each eclass should fall into one of the two categories
16 and follow the principles for that category. I'm defining
17 "wraparound" as shorthand for eclasses that export phase functions
18 because often these eclasses do all the heavy lifting, with the ebuild
19 just being a wrapper.
21 Utility eclasses are pretty well-understood. They generally shouldn't
22 export phase functions, and they can be used by a broad assortment of
23 ebuilds (anything that uses an scm, a language, init helpers, manpage
24 helpers, doc helpers, etc). They should export functions that do one
25 thing well, and which stay out of the way unless called on.
27 Wraparound eclasses are designed more for cases where ebuilds just
28 declare variables and minimize their functionality by relying on
29 inherited phase functions - the ebuild might not even implement any
30 phase functions. For example, KDE ebuilds all share a lot of common
31 logic from the eclass and just tell it which package they are
32 building. They mostly share the same upstream, and they mostly share
33 the same maintainers. This maximizes the upsides and minimizes the
34 downsides of heavily automated eclasses.
36 We get into trouble when we use wraparound eclasses:
37 1. With a broad assortment of ebuilds.
38 2. With many individual ebuild maintainers.
39 3. For things like languages or genres.
40 4. In situations where multiple wraparound eclasses could apply.
42 I think in an ideal world we'd only have pure utility and wraparound
43 eclasses. Utility eclasses would be used by "procedural" ebuilds
44 where the execution flow is in the ebuild and it calls down to the
45 eclass. Wraparound eclasses would be used by "declarative" ebuilds
46 where the execution flow is in the eclass, and the ebuild just
47 provides information that directs this flow. I think that is
48 potentially a more powerful model, but only to the extent that you can
49 write a single eclass that can handle a broad set of build/install
50 systems/needs.
52 So, for tomorrow I'm leaning towards:
53 1. Let's not ditch the status quo just yet.
54 2. Let's not expand eclass phase function logic any further.
55 3. Let's have some real discussion around what the actual problems
56 are, and whether we can start moving towards tagging all our existing
57 eclasses as utility vs wraparound.
59 Oh, and I think the term "wraparound" sucks, so if somebody has a
60 better one please toss it out there...
62 --
63 Rich