"Zack Weinberg" <z...@owlfolio.org> writes: > For additional clarity, the purpose of AC_PROG_AWK (and AC_PROG_SED and > AC_PROG_*GREP) is to find the _best available implementation_ of these > utilities, not to determine whether they exist at all. Autoconf core > code assumes that all three exist in some form. > > There are only a few uses of grep and its relatives in autoconf core > code, they're all pretty straightforward, and it might genuinely be > worth getting rid of them just because of the number of portability > headaches associated with grep.
This is good insight! Reducing the dependency on grep for autoconf may be a worthy goal then. I recall that when I tried to make use of 'grep' in some gnulib script, Jim Meyering patched it away and for trivial uses of grep I'm trying to get into a habit of avoiding it. > Sed, however, is used ubiquitously, throughout both Autoconf proper and > the M4sh support layer. It's needed for super basic things like parsing > command line options to ./configure. I don't see any way to remove this > dependency short of rewriting the entirety of Autoconf in a completely > different programming language. That's fine, and with Paul's patch it is now clear that Autoconf depends on sed during runtime of generated ./configure. I think the main aspect here is to see if we can find unnecessary dependencies on some tools, and fix them. Sometimes code that rely on 'cmp' or 'diff' can be rewritten in some other style. > Awk is not used nearly as much, but it is required by the code that > generates config.status, and then by the actual execution of > config.status. It _might_ be possible to use sed for this instead, but > the config.status generation and execution process is some of the > hairiest code in all of Autoconf. I'm gonna ballpark it at *at least* > a full-time person-month of effort. Bluntly: if Fedora wants this to > happen, Fedora needs to pay someone to do it. ... > I would like to see someone do some research on what an ergonomic, > extensible shell-type scripting language, suitable for rewriting > Autoconf in, with a core minimal enough that it *would* be possible to > make it available in the earliest stages of an architecture bootstrap, > would be like. *But it's a research project*. None of the Bourne shell > replacement languages I am aware of (e.g. zsh, fish, rc, oils) are even > *trying* to fix the most serious problems with Bourne shell. I'm not > convinced anyone even really understands what those *are*. I'm concerned about rewriting efforts, they tend to never get finished. I think we have come to the point where it is only reasonable to assume /bin/sh and that it supports some reasonable subset of POSIX shell semantics. Anything beyond that needs to be documented as a buildtime or runtime dependency. I have experimental Guix containers where /bin/sh is Gash and common Unix tools are from Gash-Utils. It doesn't run ./configure well yet, but I suppose it is only a matter of time. One way around this is to implement a limited awk in POSIX shell. For the features of awk that Autoconf needs. Has anyone looked into that? 'shawk'? That implementation could be embedded into the ./configure script and used if the script cannot find any system awk. I'm not convinced this is good use of time, though. A 'dnf install awk' is a simple solution. But that has bootstrapping issues. And these low-level assumptions are fun to discuss. /Simon
signature.asc
Description: PGP signature
