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
