Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-Smvct5/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname
On Tue, Jun 14, 2022 at 11:15 PM Ángel wrote:
>
> On 2022-06-13 at 18:32 -0700, Paul Eggert wrote:
> > Yes, all that could be done in theory, but it'd take a lot of
> > hacking and it's been decades and it hasn't happened.
> >
> > I'd rather have shell scripts "just work" in parallel with a minimu
On 6/14/22 18:55, Ángel wrote:
Do you have any handy example of configure that takes too long to run?
Sure. Coreutils, emacs. Pretty much any nontrivial configure script
takes longer than it should.
I understand that parallelization of shell scripts is nontrivial.
On 6/14/22 10:11, Nick Bowler wrote:
The resulting config.h is correct but pa.sh took almost 1 minute to run
the configure script, about ten times longer than dash takes to run the
same script. More than half of that time appears to be spent just
loading the program into pa.sh, before a single
On 2022-06-13 at 18:32 -0700, Paul Eggert wrote:
> Yes, all that could be done in theory, but it'd take a lot of
> hacking and it's been decades and it hasn't happened.
>
> I'd rather have shell scripts "just work" in parallel with a minimum
> of fuss.
If this hasn't happened, that might be becau
Chet Ramey wrote in
<211b74c0-caed-227f-ffae-b85868ef7...@case.edu>:
|On 6/13/22 6:39 PM, Paul Eggert wrote:
|> In many Gnu projects, the 'configure' script is the biggest barrier to
|> building because it takes s long to run. Is there some way that we
|> could improve its performance with
On 6/13/22 6:39 PM, Paul Eggert wrote:
> In many Gnu projects, the 'configure' script is the biggest barrier to
> building because it takes s long to run. Is there some way that we
> could improve its performance without completely reengineering it, by
> improving Bash so that it can paralleliz
