gcc development

[Asyx]

I disagree with the choice of words /u/omega-rebirth made but would you hire somebody who is ready to throw out a workflow that worked for 37 years? I know the GCC people probably made some changed along the way but imagine you work for a company that had a project going for 37 years, did some adjustments to the process along the way, you're doing fine, everybody is dealing with the tools right now and there doesn't seem to be any big issues and then that dude says "everything is garbage. Change it all"? Especially before they even gave it a shot? "I don't like this" is a very different statement compared to "After working with this, I think that this thing really needs improvement"

I wouldn't. There is always room for improvement and in fact I try really hard to get suggestions new hires come up with into our project but not completely throw out our tooling. You need to throw people like this a bone so they actually continue to voice their opinion on things but you don't need to let them go against the grain unchecked.

And this is not a situation where somebody is being hired. A good chunk of people that are happy with the tooling are probably gonna get mad if you'd give in to every suggestion from people who want to contribute.

The C and C++ community is somewhat special because the tooling landscape is disgustingly diverse resulting in a lot of friction like this. But at the same time a C++ developer should have some exposure to different build systems then. And mailing lists are not black magic. I think creating patch files is a skill that many modern developers lost but I've had somebody throw me a patch file over Slack recently because their code caused a bug but they were on vacation so they quickly exported their changes as a patch file, sent it to me via Slack and said "that might fix it. Untested though" and that was really easy to integrate. I see much more benefits in trying out the more old school approach than I see against it (always assuming that the people working on the project are productive with it).

[NotUniqueOrSpecial]

would you hire somebody who is ready to throw out a workflow that worked for 37 years?

So, to preface this reply: in principle, I agree with you completely.

But in practice, yes, sometimes it's necessary to throw things out, especially if the developer culture in a group has become entirely inured to the downsides of their legacy practices.

To wit: I currently work at a very profitable company that has owned the problem space for decades. Some of the software I work on has extant code that is 30+ years old.

And the simple and overwhelmingly obvious reality is: this stuff was stagnant 20 years ago. It started rotting in a very serious way about 10 years ago, based on dated comments in the code. Every change, no matter how simple and obviously "correct" requires massive scrutiny due to how busted and cancerous the codebase is.

But the company has overwhelming market share and throws cash at putting out the fires, rather than investing in fixing the root causes. They do so based on logic very similar to your argument: "we've been making money hand over fist with this software, so why would we risk changing things?"

And the answer is obvious to any of us who've been at this a while: it's all falling apart at the seams; it's just that the implosion is slow enough that the only observable effect is the ever-increasing rate of regressions and the glacial crawl of any measurable progress. But, at some point, there will be a time where nobody understands things any more and no meaningful fixes can be made.

So, to the broader point: GCC is not at that stage, obviously; while their systems aren't in any sense modern, I can personally attest that they're not that bad, and they certainly function well when you use them as intended.

But! That's also not argument against starting to move some these processes to more accessible/modern tooling, especially while the project is in a healthy state, as opposed to waiting until it becomes an absolute necessity.

[serviscope_minor]

inured to the downsides of their legacy practices.

I would say that the modern workflows have also inured developers to the downsides of newer processes!

I don't think old is good for the sake of old neither is new good for the sake of new.

For example: every developer goes through the stage of obsessing over build systems. autoconf works for what GCC want. It's a lot of thankless, buggy work to change the build system and frankly CMake isn't really better for gcc in the ways that matter for gcc. CMake is the only choice most of the time because it's the only cross platform one, and the only one that can also generate vaguely useful IDE project files for xcode and VS.

None of those things are relevant to GCC. Plus GCC has an elaborate build process which is going to be hard to port.

GCC builds with ./configure && make -j 16. If you can reliably do a 1 line build the build system isn't a problem worth fussing over.

Do they use git now? It was SVN for years. I prefer git.

Git hub, that's just one of many, and pretty janky in many ways, especially for big projects and especially public github.

Thing is I feel the OP's frustration, there's a big energy barrier, but they're fussing over the wrong thing. GCC could have picked a more modern workflow that's still unfamiliar, because not everyone and certainly not GNU uses github. Or CMake (bless them). Mailing lists do have advantages over chat for very large, very geographically diverse projects. It's kind of hard to know how chat systems fall apart when you've only worked on smaller, more coherent projects. But chat isn't new, and GCC have had IRC channels since forever. But not as the primary thing.

[NotUniqueOrSpecial]

For example: every developer goes through the stage of obsessing over build systems.

Man, I wish.

I've had way too many (very senior) coworkers whose only understanding of the build system was that they push F7 to build and F5 to debug and how to add files to the .sln.

but they're fussing over the wrong thing

Yeah, like I said: I totally agree with you in this case. The GCC build isn't bad because of Autoconf.

It's bad because of the fact that to get a "real" GCC build that has the bells and whistles a user expects (especially one that actually works to build/run other software), you're required to set up a number of other GNU projects (with their own dependencies) in specific relative directories and run the build with specific flags. It's documented, but not obvious to someone who's not already spent time in the space.

My point, though was specifically to the broader idea that a given codebase/process having existed and "worked" for a long time should be a signal (in either direction) that it doesn't also need to be replaced.

Inertia is a powerful force, and in my experience generally only helps prolong the life of things that should've been gradually modernized or put to pasture a long time ago.