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