| 1 |
On Sun, 25 Sep 2016 11:05:27 +0100 |
| 2 |
James Le Cuirot <chewi@g.o> wrote: |
| 3 |
|
| 4 |
> I've just started cross-compiling again for the first time in about |
| 5 |
> two years. Now I remember why I couldn't rely on bashrc for this. |
| 6 |
> elibtoolize comes from the libtool eclass and you can't inherit |
| 7 |
> additional eclasses from bashrc. |
| 8 |
|
| 9 |
Well, technically you can but it becomes really hackish :) |
| 10 |
|
| 11 |
|
| 12 |
I doubt including elibtoolize in portage/econf/pms is a viable |
| 13 |
solution: there is way too much code, N patches times M libtool |
| 14 |
versions to handle, and in rare cases one needs to call elibtoolize |
| 15 |
with some optional arguments. Specing that would be a pain for no real |
| 16 |
gain. |
| 17 |
|
| 18 |
|
| 19 |
On the other hand, we could go the complete opposite direction of what |
| 20 |
has been done in the past years with PMS: provide a generic way to |
| 21 |
extend ebuild env from profiles, with the ability to "include" |
| 22 |
some "eclasses", define default phases and pre/post phases hooks. This |
| 23 |
would have, e.g., saved the need to completely rewrite and spec epatch, |
| 24 |
avoided every PM to copy/paste default phases implementations from PMS, |
| 25 |
etc. However, this has somewhat the same disadvantage than eclasses: |
| 26 |
one commits crap there and breaks every system in subtle ways... |
Archives