From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: 40641@debbugs.gnu.org, elaexuotee@wilsonb.com
Subject: bug#40641: Building from git breaks when /bin/sh isn't bash
Date: Sun, 10 Jul 2022 00:56:08 -0400 [thread overview]
Message-ID: <87mtdhftw7.fsf@gmail.com> (raw)
In-Reply-To: <878rp4c7em.fsf@pelzflorian.de> (pelzflorian@pelzflorian.de's message of "Fri, 08 Jul 2022 10:53:21 +0200")
Hello,
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
> Wait wait Maxim, the discussion was that
> "B. Wilson" <elaexuotee@wilsonb.com> proposed
>> [PATCH] build: Let make use its hard-coded default shell
> > To: guix-patches@gnu.org
>>
> > * configure.ac: Set AM_SUBST_NOTMAKE([SHELL])
> > +# Use make's hard-coded default shell. The make in a guix profile
> > +# defaults to the Right Thing, e.g. $GUIX_ENVIRONMENT/bin/sh
>> +AM_SUBST_NOTMAKE([SHELL])
>
> Then Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> 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.
>
> elaexuotee@wilsonb.com writes:
>> Excellent. I agree it's probably not worth POSIXifying the scripts. Forcing
>> make to default to guix's bash seems like the right approach IMHO, so +1 for
>> that fix.
>
> I think we’re not on the same page. Is AM_SUBST_NOTMAKE([SHELL]) really
> problematic? Is seems like there is a legitimate use-case that foreign
> distro users with /bin/sh = dash would want “guix shell -D guix -- make”
> to just work without workaround? We could use elaexuotee’s
> AM_SUBST_NOTMAKE([SHELL]) patch, could we not?
Indeed, I had misunderstood, apologies. I've read the Autoconf/Automake
Info manuals about AM_SUBST and AM_SUBST_NOTMAKE, but I don't have a
clear understanding of the mechanisms involved.
from info '(autoconf) config.status Invocation':
-- Variable: CONFIG_SHELL
The shell with which to run ‘configure’. It must be
Bourne-compatible, and the absolute name of the shell should be
passed. The default is a shell that supports ‘LINENO’ if
available, and ‘/bin/sh’ otherwise.
So it appears to me that by default, it'd look for a shell that supports
LINENO if available, such as /bin/bash or something else? E.g., not use
the user's SHELL environment variable directly, but that can be
overridden with CONFIG_SHELL.
Using AC_SUBST_NOTMAKE([SHELL]) would cause SHELL to be substituted in
the build system files but prevent setting Make variables such as SHELL
= '/bin/...' in generated Makefiles... how do that end up causing the
Guix-provided Make to use its own "known" shell?
It seems to me that a potential pitfall would be that by adding
AC_SUBST_NOTMAKE([SHELL]), we'd change the default behavior of Autoconf,
which is to honor CONFIG_SHELL and set the SHELL Make variable based on
that; it seems it could be simpler to document that users on systems
using a Bourne incompatible shell should set CONFIG_SHELL to a Bourne
compatible one to build Guix from sources.
Is someone able to explain how the suggested fix work in more details?
Thanks,
Maxim
next prev parent reply other threads:[~2022-07-10 4:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 9:06 bug#40641: Building from git breaks when /bin/sh isn't bash elaexuotee--- via Bug reports for GNU Guix
2020-04-15 12:21 ` pelzflorian (Florian Pelz)
2020-04-17 14:57 ` elaexuotee--- via Bug reports for GNU Guix
2022-06-10 0:34 ` Maxim Cournoyer
2022-06-13 14:40 ` pelzflorian (Florian Pelz)
2022-06-14 16:09 ` Maxim Cournoyer
2022-06-21 0:20 ` elaexuotee--- via Bug reports for GNU Guix
2022-06-21 9:02 ` pelzflorian (Florian Pelz)
2022-07-04 11:22 ` elaexuotee--- via Bug reports for GNU Guix
[not found] ` <62c2cd89.1c69fb81.7ad72.92c8SMTPIN_ADDED_BROKEN@mx.google.com>
2022-07-07 21:52 ` Maxim Cournoyer
2022-07-08 8:53 ` pelzflorian (Florian Pelz)
2022-07-08 8:58 ` pelzflorian (Florian Pelz)
2022-07-08 9:51 ` elaexuotee--- via Bug reports for GNU Guix
2022-07-10 4:56 ` Maxim Cournoyer [this message]
2022-07-10 10:13 ` elaexuotee--- via Bug reports for GNU Guix
[not found] ` <62caa649.1c69fb81.5b288.1112SMTPIN_ADDED_BROKEN@mx.google.com>
2022-07-10 19:55 ` Maxim Cournoyer
2022-07-11 13:48 ` Maxim Cournoyer
2022-07-19 4:14 ` elaexuotee--- via Bug reports for GNU Guix
2022-07-21 15:29 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtdhftw7.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=40641@debbugs.gnu.org \
--cc=elaexuotee@wilsonb.com \
--cc=pelzflorian@pelzflorian.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).