Re: New libtool maintainer: request for feedback

[Alex Ameen]

Thanks for the feedback.

I completely agree about using `AC_CONFIG_COMMANDS', and actually in my 
patch where I have been creating `ltmain.in' with `autom4te' + `m4sugar' 
that is exactly what I did to make any changes synchronize into `gnulib' 
modules for example ( some minor patches to libtool's `automake' 
snippets and `libtoolize.in' were necessary as well ). In the current 
draft I had really just focused on splitting `ltmain.in' into smaller 
`m4sugar' files that were easier to understand - so I don't really have 
any strong opinions about whether `ltmain.in' vs `ltmain.m4' were 
distributed ( I see pros/cons for both ). My immediate goal is place all 
of the existing shell functions defined by `ltmain' into `m4_defun' 
blocks/wrappers so that they are usable with `m4_require' and compatible 
with existing `m4sh' routines ( although initially I am not going to 
replace any existing logic with `m4sh' since I don't want to 
unintentionally modify behavior ).

From what I have seen you are absolutely right that `libtool' repeats A 
LOT of system-probing on each invocation which is pretty wasteful. This 
puzzled me since `configure' is more than capable of producing a 
`libtool' script that skips those checks; my theory is that for a system 
wide build of `libtool' you want those platform checks since you may be 
cross-compiling - but I need to dig into the rationale further to say 
for sure. I agree that for a "libtoolized" project though only the 
relevant routines should be present since this would likely improve 
performance and make the script significantly easier for users to 
understand ( even after reading it extensively I get lost in the ~9,000 
line monolith ).

In any case I appreciate you reaching out and hope that I can get 
`libtool' to up to speed with the rest of the modern `autotools' 
ecosystem. My top priority now is processing existing patches, since I 
know those people have been waiting for a long time, but I'm excited to 
dive into the extensions above after that.


On 10/24/21 4:21 PM, Zack Weinberg wrote:
> On Sun, Oct 24, 2021, at 4:33 PM, Alex Ameen wrote:
> > Howdy,
> >
> > I just wanted to reach out and connect with y'all to introduce myself
> > and hopefully map out patches to `libtool' to improve integration with
> > `autoconf'.
> Welcome aboard!  I am delighted to hear that libtool is being maintained again.
>
> ...
> > Please feel free to reach out if you are aware of any headaches
> > `libtool' integration causes with `autoconf' development and I will be
> > more than happy to help - inline comments throughout `autoconf' refer to
> > a handful, but I imagine there are several others that are not
> > explicitly mentioned.
> Off the top of my head:
>
> It would be nice if libtoolize didn't have overlapping functionality with 
> aclocal.  More specifically, the work currently done by libtoolize's 
> func_install_pkgmacro_files should instead be done by aclocal (there may be 
> other places that need changing as well, I only skimmed libtoolize.in just now).
>
> If you can figure out a way to generate the 'libtool' script using only 
> AC_SUBST operations, instead of relying on AC_CONFIG_COMMANDS, that will be 
> substantially less fragile.
>
> While this is not a problem _for autoconf_, it is my impression that the 
> 'libtool' script repeats a bunch of system-probing work, on each invocation, 
> that could be moved to LT_INIT.  I would encourage you to pursue this change, 
> both for performance and because it would make everything libtool knows about 
> the build and host environment accessible to configure.ac code.
>
> zw