| 1 |
On 08/02/2010 08:16 PM, David Leverton wrote: |
| 2 |
> On 2 August 2010 12:11, Brian Harring <ferringb@×××××.com> wrote: |
| 3 |
>> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote: |
| 4 |
>>> Hi folks, |
| 5 |
>>> |
| 6 |
>>> I've been told that my use of eblits in dev-lang/php is something |
| 7 |
>>> I should get rid of as soon as possible. Suggested alternative by |
| 8 |
>>> ferring: use elibs. |
| 9 |
> |
| 10 |
> There's a couple of hundred lines of repeated metadata between |
| 11 |
> php-5.3.2 and php-5.3.3 - not identical, but similar enough that |
| 12 |
> there would be gains from factoring it out, and elibs won't help with |
| 13 |
> that. |
| 14 |
|
| 15 |
Sure. I was thinking of providing php.eclass with the common metadata |
| 16 |
for php-5*, including patchset code, core DEPEND and the like. With the |
| 17 |
php team rather stretched nowadays, it will take a few days before |
| 18 |
that'll happen. I'm still trying to cope with the complexity of the |
| 19 |
whole php eco-system. |
| 20 |
|
| 21 |
> Am I understanding correctly in that you didn't use an eclass to |
| 22 |
> avoid cluttering up the main eclass directory with something specific |
| 23 |
> to this one package? |
| 24 |
|
| 25 |
Yes. Actually, that was hoffie's goal, when he decided to use eblits. |
| 26 |
I continued this and actually made php5_2-sapi.eclass obsolete by using |
| 27 |
eblits in php-5.2.14. Interesting sidenote: I only needed one more eblit |
| 28 |
for this - the amount of code shared went through the ceiling. |
| 29 |
|
| 30 |
> If so, it sounds like what you really want is per-package eclasses |
| 31 |
> (maybe with elibs as well to hold the non-metadata code), which |
| 32 |
> aren't covered by GLEP33 but ought to be easy enough to add. |
| 33 |
|
| 34 |
It's actually covered by GLEP33: |
| 35 |
http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring |
| 36 |
|
| 37 |
And yes, it's one of it's most obvious advantages. I hate the clutter of |
| 38 |
php-* eclasses with passion (I'm aware most of them serve a good purpose). |
| 39 |
|
| 40 |
>> My suggestion? Split this into two, elibs, and eclass |
| 41 |
>> refactoring. |
| 42 |
> |
| 43 |
> Per-package eclasses would be beneficial IMHO regardless of the |
| 44 |
> other eclass stuff from 33, might be worth thinking about those as |
| 45 |
> another item (consistent with the existing design plans of course) if |
| 46 |
> the rest isn't going to happen soon. |
| 47 |
|
| 48 |
If we can get that going asap without waiting, I'm all for it. |
Archives