Hi,
elaexuo...@wilsonb.com writes:
> Maxim Cournoyer wrote:
>> I'll see if these Bashisms can be easily switched to POSIX variants,
>> else I'll experiment with setting the shebang of the test scripts to
>> bash.
>
> Is there any particular reason to go this route?
I can think of at least two:
Maxim Cournoyer wrote:
> I'll see if these Bashisms can be easily switched to POSIX variants,
> else I'll experiment with setting the shebang of the test scripts to
> bash.
Is there any particular reason to go this route?
Writing portable scripts is full of all sorts of pitfalls and ill-meaning
Hello,
[...]
> 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
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
> -
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
Hello,
"pelzflorian (Florian Pelz)" writes:
> Wait wait Maxim, the discussion was that
> "B. Wilson" proposed
>> [PATCH] build: Let make use its hard-coded default shell
> > To: guix-patc...@gnu.org
>>
> > * configure.ac: Set AM_SUBST_NOTMAKE([SHELL])
> > +# Use make's hard-coded default
> 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
>
"pelzflorian (Florian Pelz)" writes:
> “guix shell -D guix -- make”
> to just work without workaround?
Argh, I meant to write “guix shell -D guix -- make check” …
Regards,
Florian
Wait wait Maxim, the discussion was that
"B. Wilson" proposed
> [PATCH] build: Let make use its hard-coded default shell
> To: guix-patc...@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
Hello,
elaexuo...@wilsonb.com writes:
> "pelzflorian (Florian Pelz)" wrote:
>> Thank you for getting back to the bug. I am in the same situation in
>> that I use Guix System now. :D
>>
>> On Tue, Jun 21, 2022 at 09:20:28AM +0900, elaexuo...@wilsonb.com wrote:
>> > so you could be able to
"pelzflorian (Florian Pelz)" wrote:
> Thank you for getting back to the bug. I am in the same situation in
> that I use Guix System now. :D
>
> On Tue, Jun 21, 2022 at 09:20:28AM +0900, elaexuo...@wilsonb.com wrote:
> > so you could be able to sanity
> > check with something like
> >
> > $
Thank you for getting back to the bug. I am in the same situation in
that I use Guix System now. :D
On Tue, Jun 21, 2022 at 09:20:28AM +0900, elaexuo...@wilsonb.com wrote:
> so you could be able to sanity
> check with something like
>
> $ guix shell -C dash guix make
> $ ln -s
> Wilson, could you confirm whether there's still something to fix here?
> Else, let's close this ticket and move on.
The original issue arose on a Void Linux foreign distro installation. I have
long since converted to Guix System, so cannot easily test the original
environment.
However, Void
Hello,
"pelzflorian (Florian Pelz)" writes:
> Only the tests are affected, as far as I can tell. make runs fine.
> The issue with “gnu/local.mk” from [1] got fixed in 2019 via
> 92d00ca4661e186022732a47956a2bc0ef16be96.
>
> But Makefile.am has
>
> SH_LOG_COMPILER = $(top_builddir)/test-env
Only the tests are affected, as far as I can tell. make runs fine.
The issue with “gnu/local.mk” from [1] got fixed in 2019 via
92d00ca4661e186022732a47956a2bc0ef16be96.
But Makefile.am has
SH_LOG_COMPILER = $(top_builddir)/test-env $(SHELL)
AM_SH_LOG_FLAGS = -x -e
Probably autoconf can be
Hello,
elaexuo...@wilsonb.com writes:
> "pelzflorian (Florian Pelz)" 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 =
"pelzflorian (Florian Pelz)" 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
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 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
19 matches
Mail list logo
