Hi, elaexuo...@wilsonb.com writes:
> CONFIG_SHELL simply acts as a user override; it's not part of autoconf's core > logic. That role belongs to the SHELL macro, who's picks the first available > of > the following: > > - CONFIG_SHELL environment variable, > - SHELL environment variable, or > - /bin/sh > > See autoconf's m4sugar/m4sh.m4 for the gory details. Arguably, this should > also be updated to point to a fixed /bin/sh output fallback. > > Anyway, AM_SUBST_NOTMAKE([SHELL]), cf. '(automake) Optional', simply tells > automake to not define SHELL inside the generated Makefile. This means that > make will instead use it's default, which in our case is hard-coded to the > /bin/sh in its implicit bash-minimal dependency. For detailed info about this > behaviour of make, see '(make) Choosing the Shell'. Note, however, you will > have to do a mental sed-replace of "/bin/sh" with "<bash-minimal>/bin/sh" when > reading that page. Thanks for the extra details. So if I understand correctly, and re-reading your original message, the issue is that some tests shell scripts contain Bashisms that fail to run on POSIX shells such as Dash? Couldn't we just identify these tests with the proper shebang? e.g. '#!/usr/bin/env bash' where it is required? I've just 'ln -sf $(guix build dash)/bin/dash /bin/sh && export SHELL=/bin/sh' on my Guix System, and could rebuild Guix master from scratch successfully: make[1]: Leaving directory '/home/maxim/src/guix-master' $ echo $? 0 $ ./pre-inst-env guix describe Git checkout: repository: /home/maxim/src/guix/.git/worktrees branch: test-dash-as-bin-sh commit: bf0a646a5bcde489b602c58fbb63a93acb9d08f6 $ echo $SHELL /bin/sh $ ls -al /bin/sh lrwxrwxrwx 1 root root 66 Jul 10 15:11 /bin/sh -> /gnu/store/nm0hccsphymxi8c24xmg6ixm9vcf25xb-dash-0.5.11.5/bin/dash $ grep SHELL Makefile [...] SHELL = /bin/sh I'll now try the tests. Thanks, Maxim
