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