|
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 `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
[Prev in Thread] | Current Thread | [Next in Thread] |