1 |
On Tue, 20 Sep 2016 16:21:36 +0100 |
2 |
James Le Cuirot <chewi@g.o> wrote: |
3 |
|
4 |
> On Tue, 20 Sep 2016 17:13:50 +0200 |
5 |
> Alexis Ballier <aballier@g.o> wrote: |
6 |
> |
7 |
> > On Tue, 20 Sep 2016 13:58:32 +0100 |
8 |
> > James Le Cuirot <chewi@g.o> wrote: |
9 |
> > |
10 |
> > > On Tue, 20 Sep 2016 09:15:50 +0200 |
11 |
> > > Michał Górny <mgorny@g.o> wrote: |
12 |
> > > |
13 |
> > > > That said, I don't find the current solution really optimal. A |
14 |
> > > > lot of ebuilds (mine, for example) are not using elibtoolize, |
15 |
> > > > and I expect that they may randomly fail for some people in |
16 |
> > > > corner cases. But I don't feel like adding another eclass to |
17 |
> > > > all ebuilds in the tree is a good idea. |
18 |
> > > > |
19 |
> > > > Portage already does some configure updates in econf. How about |
20 |
> > > > we move the whole thing straight into Portage, implicitly |
21 |
> > > > activated by econf? That would certainly increase coverage, |
22 |
> > > > remove some QA violations from ECLASSDIR and possibly solve the |
23 |
> > > > problem long-term. |
24 |
> > > > |
25 |
> > > > What do you think? |
26 |
> > > |
27 |
> > > I support this. I don't know if it's as big a problem as it was |
28 |
> > > when I last looked at it but cross-compiling often failed without |
29 |
> > > the sysroot patch. Much like you, before becoming a dev, I did not |
30 |
> > > want to file a whole string of bug reports requesting that |
31 |
> > > elibtoolize be added to loads of ebuilds. |
32 |
> > > |
33 |
> > |
34 |
> > |
35 |
> > there is a simple solution to this: profile.bashrc :) |
36 |
> |
37 |
> Indeed, I did some godawful things with bashrc that make my own eyes |
38 |
> bleed but I stopped short of adding elibtoolize. It might work but if |
39 |
> it would work that reliably, why not make it standard? |
40 |
> |
41 |
|
42 |
yes it should; not sure why previous attempts aborted |