On Thu, Apr 17, 2025, at 7:31 AM, Simon Josefsson via Bug reports for autoconf wrote: > Paul Eggert <egg...@cs.ucla.edu> writes: >> On 2025-04-16 23:31, Simon Josefsson via Bug reports for >> autoconf wrote: >> >>> I tried reading through the autoconf manual to see if 'awk' is a run- >>> time dependency for running generated ./configure scripts >> >> It is a dependency, and the documentation should mention this > > Thank you for patch and background context!
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. 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. 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. >>> 0) Modify autoconf to continue to work in this situation without >>> awk, replacing it with more POSIX shell or something else? >> >> It might be possible to replace awk with Python (say), but it'd be a >> nontrivial. I doubt whether the shell itself would suffice. Probably >> not worth the effort at this point. > > Python is not available in the default Fedora 42 image either. ... > I would prefer if we can make things work with /bin/sh and as few low- > complex utilities as possible, for bootstrapping reasons. Making > Python, Rust/Go, Guile etc work on new architectures is serious work, > and sometimes people just give up (e.g., m68k, sh4, sparc64 is not in > a good state here). So I don't think that is always the right > solution. Backing this up, in roughly 2019 I was told (by Fedora maintainers) that it is not feasible to make Python available early enough in architecture bootstrap for it to be used in the build process of glibc or the C toolchain. More recently I was told the same thing about Perl. I do not know any specifics of why, but that pretty much rules out any use of either in code unavoidably emitted into generated configure scripts, such as the config.status logic. (We get away with requiring Perl for the `autoconf` program _only_ because we ship the generated configure script in the tarball of everything needed that early in architecture bootstrap.) 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*. zw
