On Wednesday 16 February 2005 20:32, Dan Armak wrote: > On Wednesday 16 February 2005 19:39, John Mylchreest wrote: > > On Wed, 2005-02-16 at 15:49 +0000, Ciaran McCreesh wrote: > > > I don't see the need for having eclasses and elibs treated as two > > > different things. The way it is now, we can have classes that do export > > > vars and eclasses that don't. > > > > Correct, but eclasses by definition are there to redefine ebuild > > behaviour, rather than be a repository of functions. > > What definition is that? Eclasses are there to keep shared ebuild code in. > Function-repository eclasses are a natural form of that, and they've always > been around. > > Take kde-functions.eclass. It's a purely function-library eclass and has > always been that way; rev 1.1 begins with the words, "This contains > everything except things that modify ebuild variables and functions" - just > like an elib. It was created more than three years ago, just a few months > after the first eclasses. (If you're interested in cvs logs, it was called > kde-dirs.eclass originally.) > > eutils.eclass is probably the best-known function repository eclass, and > it's been around for 2.5 years, too...
<cut> > > Big changes (including almost all changes to EXPORT_FUNCTIONS) aren't > allowed, period. Create a new eclass that inherits the old one and adds the > new code. It's completely safe and a lot easier. I tend to have the feeling that this GLEP misses one important point. I can't see which problem it tries to solve. The rationale in the glep is incomplete in that the issues presented can easilly be solved by being smart about eclasses. Like Dan says, this does mean that sometimes new versions are needed. Well that's very very easy. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpzdad5HJjay.pgp
Description: PGP signature
