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

["Michał Górny" <mgorny@gentoo.org>]

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

On pią, 2017-03-17 at 23:38 +0000, James Le Cuirot wrote:
> 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?

Are you talking about epunt_cxx or elibtoolize now? (this point was
about epunt_cxx)

If the latter, yes, I think it makes sense to split the patching logic
into a separate script.

> > 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.

Strictly speaking, you don't have to have it in the PMS. This can be
left purely as Portage extension, much like gnuconfig hacking is right
now.

> 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.

Nice, that was exactly my plan. I'll create a git.g.o repo for this
in a few days, and commit the patches there. Would you be interested
in working on splitting the script again/updating your stand-alone
version?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]