bug-autoconf
[Top][All Lists]
Advanced

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

[sr #110434] autotools idea: use faster/more portable dirty job tool tha


From: Zack Weinberg
Subject: [sr #110434] autotools idea: use faster/more portable dirty job tool than sh
Date: Fri, 8 Dec 2023 11:44:05 -0500 (EST)

Update of sr#110434 (group autoconf):

                Severity:              3 - Normal => 1 - Wish               
                  Status:                    None => Wont Do                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

This isn't a bad idea in principle, but it suffers from a chicken-and-egg
problem.  Starting from nothing, how do you _get_ that better scripting
language?  One of Autoconf's big remaining advantages over meson is that
"./configure" is guaranteed to work anywhere /bin/sh and the portable subset
of the POSIX shell utilities exist.

We could ship, say, an embedded copy of Lua, but that's a lot of code (~
30,000 lines of code; 12x larger than the current minimum size of a generated
configure script), and also now you have to have a C compiler, even if the
package you wanted to build doesn't need one itself.

Also, unless you make this hypothetical better scripting language
*bug-for-bug* compatible with /bin/sh and the portable subset of the POSIX
shell utilities, every configure.ac and every third-party m4 macro would need
to be rewritten to take advantage of it, which is, practically speaking, never
going to happen.  There are still projects using autoconf 2.13 because the
compatibility break between 2.13 and 2.50 was too much to ask!

So, with regrets, we're not going to do this.  Alternative suggestions for
you:

- Work on YSH <https://www.oilshell.org/> which actually aims to be a better,
or at least faster, scripting language that is still bug-for-bug compatible
with /bin/sh etc etc.
- Add a mode to Automake in which it emits Makefiles that require GNU make and
therefore don't need quite so many inefficient embedded shell scripts (I'm
particularly thinking of the way it compiles C to object files here).
- Add a mode to Automake in which it emits build.ninja files instead of
Makefiles.
- Teach automake how to build shared libraries *without* using libtool. 
Libtool is an unmaintained "big ball of mud"
<https://wiki.c2.com/?BigBallOfMud> and most of what it does is unnecessary
anymore.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?110434>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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