| 1 |
On Tue, 20 Sep 2016 13:58:32 +0100 |
| 2 |
James Le Cuirot <chewi@g.o> wrote: |
| 3 |
|
| 4 |
> On Tue, 20 Sep 2016 09:15:50 +0200 |
| 5 |
> Michał Górny <mgorny@g.o> wrote: |
| 6 |
> |
| 7 |
> > That said, I don't find the current solution really optimal. A lot |
| 8 |
> > of ebuilds (mine, for example) are not using elibtoolize, and I |
| 9 |
> > expect that they may randomly fail for some people in corner cases. |
| 10 |
> > But I don't feel like adding another eclass to all ebuilds in the |
| 11 |
> > tree is a good idea. |
| 12 |
> > |
| 13 |
> > Portage already does some configure updates in econf. How about we |
| 14 |
> > move the whole thing straight into Portage, implicitly activated by |
| 15 |
> > econf? That would certainly increase coverage, remove some QA |
| 16 |
> > violations from ECLASSDIR and possibly solve the problem long-term. |
| 17 |
> > |
| 18 |
> > What do you think? |
| 19 |
> |
| 20 |
> I support this. I don't know if it's as big a problem as it was when I |
| 21 |
> last looked at it but cross-compiling often failed without the sysroot |
| 22 |
> patch. Much like you, before becoming a dev, I did not want to file a |
| 23 |
> whole string of bug reports requesting that elibtoolize be added to |
| 24 |
> loads of ebuilds. |
| 25 |
> |
| 26 |
|
| 27 |
|
| 28 |
there is a simple solution to this: profile.bashrc :) |
| 29 |
|
| 30 |
|
| 31 |
|
| 32 |
i think there was a project/idea to do this in a cleaner way, supported |
| 33 |
by diego, like 10 years ago, but i cant remember more |
Archives