On 25/03/19 22:40 +0000, Tomasz Kłoczko wrote:
On Mon, 25 Mar 2019 at 21:17, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
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.
So why are you bringing them up in a thread about /bin/sh?
Speaking about gcc build improvements. Just one number:
[tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac | wc -l
42
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,
Why?
The GCC tree contains lots of quite separate subsystems, which are
maintained semi-independently by different groups of people. It makes
sense for me to maintain libstdc++-v3/configure.ac and
libstdc++-v3/acinclude.m4 without worrying how my changes affect the
rest of the tree.
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😋
This seems like a rambling irrelevant tangent. Please try to stick to
the point so your emails are a sensible length.
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😋
What SIGSEGVs? Do you mean SIGABRT, raised by assert() or abort(),
which is how the tests work?
(Jakub don't take this personally please .. I'm really joking)
Maybe don't bother saying it then.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
