unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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




  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).