Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

[James Le Cuirot <chewi@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

On Fri, 17 Mar 2017 18:14:12 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> Since the bug about libtool.eclass [1] has not received any attention, I
> hereby declare maintainer timeout and start working on improving
> the eclass.
> 
> The main goals are to:
> 
> a. stop requiring every single autoconf ebuild to call elibtoolize
> manually (and effectively having half-'broken' repository),

Good! This will help immensely with cross-compiling.

> 1.1. split the function into new eclass (PATCH already sent),

The function itself is quite complex. Perhaps this should also go into
a separate package?

> 3. copy elibtoolize logic to Portage, and make it apply implicitly
> on econf [do we need to apply it elsewhere?]; disable explicit
> libtoolize when Portage supports that.

Related to the above point, if you make it part of econf then it needs
to be part of PMS and that's quite a complex beast to have in the spec.
It has been suggested twice on this list (once quite recently) that the
script itself should put into a separate package for this reason. Then
PMS just needs to say "install and use this script" without any further
detail.

Back in September, I tried turning the eclass into an external script
with very few changes to start with, just as a proof of concept. I
removed the few references to other eclass helpers but still retained a
little dependence on variables exported by Portage. I then stuck a call
to this to near the top of econf() and tried out some packages,
including those that had failed on me before. It worked very well
indeed. I don't recall encountering any issues.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]