1 |
On Fri, 17 Mar 2017 18:14:12 +0100 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hi, everyone. |
5 |
> |
6 |
> Since the bug about libtool.eclass [1] has not received any attention, I |
7 |
> hereby declare maintainer timeout and start working on improving |
8 |
> the eclass. |
9 |
> |
10 |
> The main goals are to: |
11 |
> |
12 |
> a. stop requiring every single autoconf ebuild to call elibtoolize |
13 |
> manually (and effectively having half-'broken' repository), |
14 |
|
15 |
Good! This will help immensely with cross-compiling. |
16 |
|
17 |
> 1.1. split the function into new eclass (PATCH already sent), |
18 |
|
19 |
The function itself is quite complex. Perhaps this should also go into |
20 |
a separate package? |
21 |
|
22 |
> 3. copy elibtoolize logic to Portage, and make it apply implicitly |
23 |
> on econf [do we need to apply it elsewhere?]; disable explicit |
24 |
> libtoolize when Portage supports that. |
25 |
|
26 |
Related to the above point, if you make it part of econf then it needs |
27 |
to be part of PMS and that's quite a complex beast to have in the spec. |
28 |
It has been suggested twice on this list (once quite recently) that the |
29 |
script itself should put into a separate package for this reason. Then |
30 |
PMS just needs to say "install and use this script" without any further |
31 |
detail. |
32 |
|
33 |
Back in September, I tried turning the eclass into an external script |
34 |
with very few changes to start with, just as a proof of concept. I |
35 |
removed the few references to other eclass helpers but still retained a |
36 |
little dependence on variables exported by Portage. I then stuck a call |
37 |
to this to near the top of econf() and tried out some packages, |
38 |
including those that had failed on me before. It worked very well |
39 |
indeed. I don't recall encountering any issues. |
40 |
|
41 |
-- |
42 |
James Le Cuirot (chewi) |
43 |
Gentoo Linux Developer |