1 |
On pią, 2017-03-17 at 23:38 +0000, James Le Cuirot wrote: |
2 |
> On Fri, 17 Mar 2017 18:14:12 +0100 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> |
5 |
> > Hi, everyone. |
6 |
> > |
7 |
> > Since the bug about libtool.eclass [1] has not received any attention, I |
8 |
> > hereby declare maintainer timeout and start working on improving |
9 |
> > the eclass. |
10 |
> > |
11 |
> > The main goals are to: |
12 |
> > |
13 |
> > a. stop requiring every single autoconf ebuild to call elibtoolize |
14 |
> > manually (and effectively having half-'broken' repository), |
15 |
> |
16 |
> Good! This will help immensely with cross-compiling. |
17 |
> |
18 |
> > 1.1. split the function into new eclass (PATCH already sent), |
19 |
> |
20 |
> The function itself is quite complex. Perhaps this should also go into |
21 |
> a separate package? |
22 |
|
23 |
Are you talking about epunt_cxx or elibtoolize now? (this point was |
24 |
about epunt_cxx) |
25 |
|
26 |
If the latter, yes, I think it makes sense to split the patching logic |
27 |
into a separate script. |
28 |
|
29 |
> > 3. copy elibtoolize logic to Portage, and make it apply implicitly |
30 |
> > on econf [do we need to apply it elsewhere?]; disable explicit |
31 |
> > libtoolize when Portage supports that. |
32 |
> |
33 |
> Related to the above point, if you make it part of econf then it needs |
34 |
> to be part of PMS and that's quite a complex beast to have in the spec. |
35 |
> It has been suggested twice on this list (once quite recently) that the |
36 |
> script itself should put into a separate package for this reason. Then |
37 |
> PMS just needs to say "install and use this script" without any further |
38 |
> detail. |
39 |
|
40 |
Strictly speaking, you don't have to have it in the PMS. This can be |
41 |
left purely as Portage extension, much like gnuconfig hacking is right |
42 |
now. |
43 |
|
44 |
> Back in September, I tried turning the eclass into an external script |
45 |
> with very few changes to start with, just as a proof of concept. I |
46 |
> removed the few references to other eclass helpers but still retained a |
47 |
> little dependence on variables exported by Portage. I then stuck a call |
48 |
> to this to near the top of econf() and tried out some packages, |
49 |
> including those that had failed on me before. It worked very well |
50 |
> indeed. I don't recall encountering any issues. |
51 |
|
52 |
Nice, that was exactly my plan. I'll create a git.g.o repo for this |
53 |
in a few days, and commit the patches there. Would you be interested |
54 |
in working on splitting the script again/updating your stand-alone |
55 |
version? |
56 |
|
57 |
-- |
58 |
Best regards, |
59 |
Michał Górny |