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