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