On 08/03/2010 12:17 AM, David Leverton wrote: > On 2 August 2010 22:40, Matti Bickel <[email protected]> wrote: >> On 08/02/2010 08:16 PM, David Leverton wrote: >>> If so, it sounds like what you really want is per-package eclasses >>> (maybe with elibs as well to hold the non-metadata code), which >>> aren't covered by GLEP33 but ought to be easy enough to add. >> >> It's actually covered by GLEP33: >> http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring > > I interpreted that more as a way to organise the global eclasses
Yes, I thought you were talking about them. Introducing eclasses into
the rest of the tree - is that possible from the implementation side?
That is, how can PMs support that w/o much hassle? Are there any speed
considerations that need to be taken into account?
I like the idea. Having dev-lang/php/php-common.eclass makes a lot more
sense then putting it into ${PORTDIR}/include/eclass.
PHP will still need global eclasses for PEAR and pecl stuff, so I like
them moving forward, too. And hiding them into
${PORTDIR}/include/eclass/php/ might be a good first step.
signature.asc
Description: OpenPGP digital signature
