| 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 |
> |
| 7 |
|
| 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. |
| 13 |
|
| 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. |
| 20 |
|
| 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. |
| 26 |
|
| 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. |
| 35 |
|
| 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. |
| 41 |
|
| 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. |
| 51 |
|
| 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. |
| 58 |
|
| 59 |
Oh, and I think the term "wraparound" sucks, so if somebody has a |
| 60 |
better one please toss it out there... |
| 61 |
|
| 62 |
-- |
| 63 |
Rich |
Archives