Hi, everyone. Quoting the top of libtool.eclass:
# @DESCRIPTION: # 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 <http://dev.gentoo.org/~mgorny/>
pgpeAtPAC56k9.pgp
Description: OpenPGP digital signature
