Re: Bison 3.7 released [stable]

[Frank Heckenbach]

Akim Demaille wrote:

> > - The umask problem with installed directories (last time I said
> >  it's about $prefix/share/bison, but it's actually all installed
> >  directories including $prefix/bin etc. if they're newly created --
> >  I hadn't noticed since they existed before on my system). But now
> >  I've read something about it and it seems to be a known, wontfix,
> >  problem.
> 
> I don't remember about that.

https://lists.gnu.org/archive/html/bug-bison/2020-05/msg00085.html

> I could use a pointer to this "wonfix"
> if you still have it at hand.

https://lists.gnu.org/archive/html/automake/2019-01/msg00000.html
(1½ years ago, not even a reply)

> > - Also well-known for a long time, but just to point out the
> >  ridiculousness of non-parallelizable configure (and to brag
> >  about my new CPU :)
> > 
> >  % time ./configure --prefix=/usr
> >  real    0m18,328s
> >  user    0m14,747s
> >  sys     0m2,915s
> >  % time make -j
> >  real    0m1,179s
> >  user    0m13,277s
> >  sys     0m1,684s
> 
> W00t???  13 seconds???  How many cores do you have?

It'a an AMD Ryzen 9 3900X, 12 cores plus hyperthreading.

> >  Clearly, we're long past the point where configure takes longer
> >  than make -- by now we can actually say that build time is
> >  negligible in comparison to configure time, even for packages of
> >  quite some complexity such as Bison. But I know you can't do
> >  anything about it.
> 
> Yes.  But I also think it is not really much of a problem.  Most
> people install software via some distro, as binaries.  And for
> developers like me, configure is rarely run: configure once, make
> many.

Yeah, probably. But IIRC some packages run configure in each
subdirectory or so. I haven't built such a package in a while, but
unless they can parallelize the configures against each other from
the top level, it seems this would take rather long (relatively) on
modern CPUs.

Regards,
Frank