[Top][All Lists]

[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: Zlobin Nikita
Subject: [sr #110434] autotools idea: use faster/more portable dirty job tool than sh
Date: Wed, 27 Jan 2021 08:06:51 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Falkon/3.1.0 Chrome/80.0.3987.163 Safari/537.36


                 Summary: autotools idea: use faster/more portable dirty job
tool than sh
                 Project: Autoconf
            Submitted by: nick87720z
            Submitted on: Wed 27 Jan 2021 01:06:49 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None



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
- Portability within Unix standards
- 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.
- not only for unix
- require main dev tool (cmake, waf, meson, etc) in all stages, including

Proposal: use fast scripting language for dirty job instead of shell (even
Example languages: lua, python, perl
- 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
- 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.
- 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.
- 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.


Reply to this item at:


  Message sent via Savannah

reply via email to

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