Hi, everyone.

Quoting the top of libtool.eclass:

# This eclass patches ltmain.sh distributed with libtoolized packages with the
# relink and portage patch among others
# Note, this eclass does not require libtool as it only applies patches to
# generated libtool files.  We do not run the libtoolize program because that
# requires a regeneration of the main autotool files in order to work properly.

However, it seems that over time the eclass has grown huge to apply
a lot of random patches not only to libtool but also to generated
configure scripts etc.

It looks like the original intent is that the eclass would be used for
all autotools-based builds. It's called directly by some packages, more
frequently indirectly called by various eclasses (gnome2, xfconf...)
and also at the end of eautoreconf.

That said, I don't find the current solution really optimal. A lot of
ebuilds (mine, for example) are not using elibtoolize, and I expect
that they may randomly fail for some people in corner cases. But I
don't feel like adding another eclass to all ebuilds in the tree is
a good idea.

Portage already does some configure updates in econf. How about we move
the whole thing straight into Portage, implicitly activated by econf?
That would certainly increase coverage, remove some QA violations from
ECLASSDIR and possibly solve the problem long-term.

What do you think?

Best regards,
Michał Górny

Attachment: pgpeAtPAC56k9.pgp
Description: OpenPGP digital signature

Reply via email to