[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New libtool maintainer: request for feedback

From: Alex Ameen
Subject: Re: New libtool maintainer: request for feedback
Date: Sun, 24 Oct 2021 17:03:00 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

Thanks for the feedback.

I completely agree about using `AC_CONFIG_COMMANDS', and actually in my patch where I have been creating `' 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 `' were necessary as well ). In the current draft I had really just focused on splitting `' into smaller `m4sugar' files that were easier to understand - so I don't really have any strong opinions about whether `' 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:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]