mainAutoconf - Support: sr #110434, autotools idea: use faster/more...

 
 

sr #110434: autotools idea: use faster/more portable dirty job tool than sh

Submitter:  Zlobin Nikita <nick87720z>
Submitted:  Wed 27 Jan 2021 01:06:49 PM UTC
   
 
Priority:  * 5 - Unprioritized Severity:  1 - Wish
Status:  Wont Do Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 08 Dec 2023 04:44:05 PM UTC, 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.

Zack Weinberg <zackw>
Group administrator
Wed 27 Jan 2021 01:06:49 PM UTC, original submission:  

For summary:
- Shell is far from fastest scripting tool even for relatively fast shells like dash.
- Posix shell is only for posix, while devs keep projects buildable for non-unix platforms, like windows.
- Other tools (cmake, meson) feature both speed and greater portability, but require core tool in all stages, including build configuration.

Problem could be solved by using way faster scripting language, but as far as I understand, gnu project is unlikely to use it if there's no implementation under gpl-like license. So, now same but more verbosely, with pros and cons.

Note: I'm not sure if below affects only autoconf. Probably other autotools components need adaptation. But configuration stage is primary in my opinion - lone autoconf is nice to use with any build system, including ninja, while automake certainly depens in AC. So..... (let's start)

Issues from using shell language for dirty job
pros:
- Portability within Unix standards
cons:
- Slow due to Shell language used for dirty job. Of course, there are faster shells, like Dash, but... see below issues.
- Posix shell compliance is noop when tested with bash
- - bash --posix just enables existing posix-compliant scripts to run -> it will never warn about some non-posix features used
- - bash documentation wrongly lists some bash-specific features as basic shell features
- - developing true posix shell scripts is achievable by testing, e.g., with dash shell. But some existing packages use bashisms in build code, thus requiring bash in reality. Keeping both is somewhat cumbersome.
- Even dash is not as fast by nature, compared with some scripting languages.

Issues from other build-systems: cmake, waf, meson, etc.
pros:
- not only for unix
cons:
- require main dev tool (cmake, waf, meson, etc) in all stages, including configuration

Proposal: use fast scripting language for dirty job instead of shell (even posix).
Example languages: lua, python, perl
python:
- simple to learn. As they say, first useful code may be written after just look to existing code (no need to traverse language ref)
- as result, looks like super-popular
- as far as I know, far from fastest scripting language even among pure cross-os subset
lua:
- claimed to be among fastest scripting language
- Some say about bad versatility due to missing basic functionality like round(), yet low dev-friendliness due to inability to print object structures as in python.
- As result it seems, that few people use it.
perl:
- listed just to accompany python item
- probably it's faster than python
- uses artistic gpl unlike python (PSF) and lua (MIT), so could be more wanted for gnu project like autoconf.

Expected enhancements:
- Great speed boost in all cases
- Portability is same as for used dirty job language, even no need for MinGW.
Requirements:
- Requires various upgrades for existing autotools-based projects, ranging from release config stuff regenerating to rewrite for some shell code, most likely used for configure.ac and 3rd-party ac/m4 scripts.

Would be great if automake derivatives could be created for make alternatives, including ninja. Well, I never even used ninja, but e.g. in gentoo meson-based packages prefer it over make for basic level build tool.

Zlobin Nikita <nick87720z>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by nick87720z (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-08 zackw Severity3 - Normal 1 - Wish
        StatusNone Wont Do
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code