bug#40641: Building from git breaks when /bin/sh isn't bash

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello,

elaexuotee@wilsonb.com writes:

> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:
>> On Wed, Apr 15, 2020 at 06:06:25PM +0900, elaexuotee--- via Bug reports for GNU Guix wrote:
>> > When building from git, ./bootstrap ends up generating (via automake) several
>> > Makefiles that set SHELL = /bin/sh. However, some targets contain rules that
>> > make use of bashisms. This leads to breakage when /bin/sh is something other
>> > than bash.
>> > 
>> > In particular, I am building from a foreign distro which links /bin/sh to dash.
>> > Currently, this ends up breaking the build, the details of which I reported
>> > to guix-devel in [0].
>> 
>> <https://bugs.gnu.org/25258> is related.  Your workaround may be more welcome.
>> 
>> Regards,
>> Florian
>
>
> Florian,
>
> Thanks for the pointer. I ended up doing a little bit of sleuthing and think
> I figured out a relatively clean fix---a simple one-liner in configure.ac.
> Attached is a proof-of-concept patch against master (974bf81776).
>
> Currently, autoconf sets make's shell to whatever it thinks is best. On a
> foreign distribution, this often ends up something external to guix profile.
> However, when this isn't bash, we run into problems.
>
> The patch's idea is to let make use its hard-coded default shell. A guix-built
> make will correctly fallback to whichever sh is in the profile, so for `guix
> environment guix' this effectively becomes $GUIX_ENVIRONMENT/bin/sh. For
> example,
>
>     $ echo '$(info $(SHELL))' | make -f -
>     /gnu/store/29jhbbg1hf557x8j53f9sxd9imlmf02a-bash-minimal-5.0.7/bin/sh
>     make: *** No targets.  Stop.
>
> I belive this should do the Right Thing. However, is there anything I am
> missing? Perhaps this change would break build scenaries I am not thinking of?

This seems odd to me.  Perhaps it'd be cleaner to detect which shell is
used at configure time to detect when /bin/sh != Bash, and warn that if
there are issues, the user should set the SHELL variable to Bash.

Or if the Bashisms are scarce enough, perhaps we can rewrite the
routines in POSIXly correct shell, although this being a GNU project I
don't really see the merit of forcing lesser shells (and less readable
code) on ourselves.

Could you provide a list of the problematic targets?  Or if my
suggestion sounds good, give it a shot?

Thanks :-)

Maxim