On Tue, 26 Mar 2019 at 08:57, Jonathan Wakely <jwakely@fedoraproject.org> wrote:
[..] 
>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?

Really?
Really do you want me to answer on the question "why there is no any sense repeat 42 times some tests on the source code configuration stage?" ??
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.

Decades ago on the begging of the gcc development it was only handful developers around which been able to build gcc because compiler it is still not easy piece of the code to build.
To help in that process and to minimise those less skilled people mistakes decision about inclusion of the other projects code into gcc tree has been made. It was really long time ago an in mean time many tools around gcc has been developed to guarantee that exact libraries or tools would be present in for example gcc build environment.
Best example: pkgconfig.
However gcc is like some time capsule and preserved that initial state quite well straight in the code.
Seems like you do not understand the impact of the fact that some parts of the gcc code are older than some people reading this list today.

As same as not keeping in po/ directories .pot files is not helping translators the same is with including other project code is not today helping in gcc development process. gcc as the project bottleneck is on those few people who are gcc maintainers. Maintaining code of those inclusions eats part of that precious man/hour resources.
Everything else can be scaled horizontally.

People like Jakub are thinking that they are helping other people (and by this saving some resources) by spending time on updating and committing .pot files changes, and as well syncing other projects code in gcc tree and they are right .. they are only thinking that it is still truth.
If may I one more time quote one of my beloved Latin sentences: "errare humanum est perseverare autem diabolicum".
Which can be translated to "to err is human, but to persist in error (out of pride) is diabolical".

All about I'm asking is just wake up and look around because few things have changed in last decades.
Consequence of those separations will be that some source code configurations test will be repeated .. so "do we need faster /bin/sh or not?" (if moving to meson would be to difficult).

Look on clang/llvm. People maintaining those projects already divided some nonpolitical trees and they are keeping some parts separately. The same was with Xorg.
So are those Xorg or clang developers are wrong about dividing and deliberately forcing to repeat many times some configuration stage tests?

Answer on that question is "No, they are not" because chance to have situation that some of those (sub)projects tests  will be executed in parallel on some well designed packages build machinery are now quite high.

Simple sometimes on solving some issues trying to crush them in straight confrontation is not the best way to win.
Current gcc state in many areas are really bad because within nonpolitical tree some separations already have been made which make whole build process not scaleable. This is quite easy to spot on that graph which I've decided to post here. In other words gcc source code tree is already in some "brain split" state between be nonpolitical tree and something which is not.
This not my decision about which one model for gcc should be chosen.
What worries me id that I can only bet that some decisions about internal separations within gcc tree had some more aesthetic than technical background/context.

As you see whole topic of the gcc has many sometimes orthogonal (sometimes not) aspects. To reach healthy state bore than few things simultaneously needs to be carefully balanced. Only part of that topic is related to /bin/sh and that part stretches waaay beyond gcc.

I'll try to hold my finger away from this topic because I think that I've already managed to put enough solid context around more than few things. If someone still do not understand what is discussed after pouring here such bucket of facts it not my problem. I've done all what I can and able to convince few people.
My understanding is that now it is more or less only matter of time to make some decisions and I'm not going to press on anyone.

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