[gentoo-dev] Fwd: Inheritance in Ebuilds

[Dan Armak]

Hi all,

This is an idea of mine which I sent to drobbins. With his blessing I'll 
begin testing on the kde ebuilds. Ideas welcome!

----------  Forwarded Message  ----------

Subject: Inheritance in Ebuilds
Date: Thu, 20 Sep 2001 13:29:21 +0300
From: Dan Armak <danarmak@g.o>
To: drobbins@g.o

Hi drobbins,

I've had an idea: make inheriting ebuilds, and generic "base" ebuilds.
Please tell me what you think. Personally I like this idea very much.

New ebuilds are as a rule a pain to write. Our skel.build provides a good
example to study, but is uncomfortable to adjust. I usually copy a similar
existing ebuild and modify that.

However, most ebuilds are actually very similar. The kde ebuilds are a good
example. All kde apps confirm to a standard [make -f Makefile;] configure;
make; make install pattern. Their ebuilds vary only in their dependencies and
the options passed to configure.

Some time ago I added the objprelink option to the kde-base ebuilds, and that
set me thinking. I had to change many files in an identical way. The files
were, however, sufficiently dissimilar that I could not write a simple sed
command or script to take care of the issue.

My idea is like class inheritance: all common functionality should be defined
and implemented in a single location. New common features will then be very
easy to add; bugs in common features, easy to find and fix. We get all the
benefits of class ineritance. Only the properties specific to the ebuild
should actually be defined in it.

An example ebuild for a kde app will then be reduced to something like this:

<header>
source /usr/portage/common/kde-generic.build
DEPEND="$DEPEND app-foo/foo app-foo/foo2"

src_install() {
src_install2 # see explanation for this further down
dobin "extra bin not installed by make install"
}

-- cut here --

A perfectly standard ebuild could then, in theory, be reduced to just a
header, source statements and DEPEND definitions.

The kde-generic.build file would define some generic deps, like kde-libs. It
would also define default functions. These would be called (for example)
src_unpack2(), src_compile2(), etc. For a kde ebuild, these functions would
take care of common things like KDEDIR, QTDIR handling, qtmt, objprelink etc.
etc.

The generic ebuild would then say:
src_install() { src_install2 }
...
Repeat for every ebuild function. This keeps the actual code in helper
functions with the "2" prefix. The inheriting ebuild has three choices:
1) Let the default src_install() stay.
2) Override with a custom src_install() that calls src_install2() at some
point, as in the above example.
3) Override with a completely custom function.

This way, ebuild writers can concentrate on their package pecularities and
leave the generic kde code, for example, to me. With such a scheme, I
wouldn't have needed to update all kde-dependant ebuilds after the /usr
switch, as I did yesterday.

Now, beyond kde. The gnome packages are AFAIK not very similar to one
another, although they should be - my scheme is a unifying one. In any case,
I think that if this works, eventually we'll have a base "virtual" ebuild
from which all other ebuilds will inherit, which will define the same default
function that are currently defined in ebuild.sh (I think that's the place).
Then there will be several layers of inheritance, or maybe ebuilds will
inherit from several generic ebuilds at once, which would make things really
interesting. That way we could plug in all sorts of extensions and helper
functions. I have ideas like unified output for messages. In my view this is
much better than putting such functions in the ebuild/emerge utils' code
 base.

An added advantage is that this scheme isn't binding. A developer can always
write an ebuild of his own, in the current style. In fact, I could
"centralize" kde-base right now, and it needn't affect anything else.
Developers could source different things according to their style and purpose.

Well, what do you think?

Note from drobbins: the "base" inherited ebuilds are to be called eclassses, 
with .eclass extensions.

--

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel