On Mon, 25 Mar 2019 at 21:17, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:

On Mon, Mar 25, 2019 at 08:18:34PM +0000, Tomasz Kłoczko wrote:
> Switching to other than bash sh interpreter allow reduce total gcc package
> build time by ~5%.

OK. But that just shows that it is — possibly — worth to switch the gcc build
to a different shell, by working with gcc upstream. Nothing should be
extrapolated from this to other packages and in particular to their
spec files.

Zbyszek .. please .. you are wrong about that I'm using here extrapolation.

I've posted only small fragment of what kind of data I'm collecting in my infrastructure.

gcc has own set of issues which I've exposed here partially in last 2-3 weeks.

All those issues are way more important than what is used as /bin/sh.

Really.

Speaking about gcc build improvements. Just one number:

[tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac | wc -l

Funny. Looks like current Fedora gcc poses "The answer to the ultimate question of life, the universe and everything" 😀

What does this 42 means in this case? It means that during whole gcc build are repeated 42 times some subset of autoconf tests. How it was possible to loose that?!? 🤔

gcc is quite monolithic and it should have only one configure.ac. Yes, am/ac can handle multiple gettext domains in single build tree so even this is not the obstacle. How to do this? Just peak on gimp, gtk3 and many other (however those two are kind of out of book examples).

IMO by such transition to single ac it should be possible to shorten gcc build time (guessing a bit) by another 10% (optimistically).

However IMO it would be better move gcc build framework to meson (because as I wrote few days ago ac/am/lt is effectively dead by now by how it is maintained by GNU people and moving those tools maintenance outside GNU project domain will be not easy task).

Just in case: cmake as ac/am/lt replacement is not IMO good because it is yet another project in which coding process maintainers are trying to solve famine problems on Earth.

cmake is written in C++ and additionally its C++ code uses exceptions and RTT (only this says that says something .. not so good).

Speaking about cmake. Recently trying to fix some cmake issues I found that cmake build using boostrap and cmake themselves does not produce the same results because looks like cmake developers are not using cmake to develop cmake which is really hilarious😋

Moving to meson (with all necessary tests in one place fired one time only) probably should shorten gcc build time by another few percents (maybe even more). I'm almost sure that with not so big effort in 2-3 man/weeks it would be possible to reduce gcc build time by at least 1/3 (totally).

Is it worth to divert some people resources to do that? IMO definitely yes as sooner or later gcc build should allow speedup whole gcc development process (during last New Year I've started gcc build on my old laptop and it took on it almost 25h).

However I'm fully aware that on top of moving to meson it will be another chunk of man/hours resources and this could be painful for Jakub as it will be necessary to sort out all those SIGSEGVs in gcc test suite and stop doing his gcc magic😋

(Jakub don't take this personally please .. I'm really joking)

kloczek

Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH