On Tue, 20 Sep 2016 16:21:36 +0100
James Le Cuirot <ch...@gentoo.org> wrote:

> On Tue, 20 Sep 2016 17:13:50 +0200
> Alexis Ballier <aball...@gentoo.org> wrote:
> 
> > On Tue, 20 Sep 2016 13:58:32 +0100
> > James Le Cuirot <ch...@gentoo.org> wrote:
> >   
> > > On Tue, 20 Sep 2016 09:15:50 +0200
> > > Michał Górny <mgo...@gentoo.org> 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 :)  
> 
> Indeed, I did some godawful things with bashrc that make my own eyes
> bleed but I stopped short of adding elibtoolize. It might work but if
> it would work that reliably, why not make it standard?
> 

yes it should; not sure why previous attempts aborted

Reply via email to