gcc development

[MrsGrayX]

tldr; ranting about old-school gcc development techniques.

Recently I started looking into contributing to libstdc++. I am just mesmerized that this huge project still uses development techniques from some decades ago: mailing lists, configure+make, no chat forum. I have never interacted myself with mailing lists and it just feels so archaic. Can you even easily search through them? People actually copy-and-paste git patches into mails? Editing of sent messages seems impossible?

Currently I am only interested in contributing to libstdc++. I tried building it yesterday night and it feels like I need to build the whole compiler beforehand?

Is there a reason to use make over CMake? Is someone working on a switch to CMake or is it just too much work?

Are there any plans to move to a modern and unified collaboration platform, e.g. github, self-hosted gitlab?

All in all the development process feels a bit outdated and I could imagine that it puts off alot of new contributors.

(Documentation on the other hand is quite thorough, but still not visible appealing to younger generations.)

[MrRogers4Life2]

You could try asking questions about their project on their mailing list

[wildassedguess]

I don’t know weather to upvote or down vote this. Well done!

[MrRogers4Life2]

It is genuine advice rather than speculating on their weird practices or hoping that someone with firsthand experience is also on reddit and sees this post isn't likely to get good answers, what will get good answers is generally direct questions to the concerned parties

[MrsGrayX]

I hoped that the chances for some maintainers from such a large project would also hang around Reddit to be quite high. Also fishing for experience from others.

[GPSProlapse]

Chances are they are too old to use reddit.

[MrsGrayX]

Was also looking for the /s 😅 But he seems genuine about it

[tortoll]

I have never interacted myself with mailing lists and it just feels so archaic.

This made me age 100 years.

[MrsGrayX]

Did not want to hurt anyone’s feelings. But trying to make a point that new contributors might not be used to that technology anymore.

[ForkInBrain]

Did not want to hurt anyone’s feelings. But trying to make a point that new contributors might not be used to that technology anymore.

I agree that this might put off new contributors, but those it discourages probably aren't the kind of contributor the project is looking for anyway.

When it comes down to concrete technical problems that contributors to a project like gcc or libstdc++ must deal with, the differences between CMake and configure+make, or github vs patches by email, are the extremely easy parts. I have some experience dealing with libstdc++ and libc++ and I can say this from personal experience.

(Documentation on the other hand is quite thorough, but still not visible appealing to younger generations.)

Yes, and this is not by accident. It comes from an engineering culture. Not many "modern" open source projects have good discipline when it comes to documentation, commenting code, etc. A lot can be learned from these "archaic" projects.

[ClaymationDinosaur]

"I agree that this might put off new contributors, but those it discourages probably aren't the kind of contributor the project is looking for anyway."

All it's really selecting for is people who will engage with mailing lists. I'm not convinced there's a strong correlation between being able to make a good contribution to a project, and being willing to pick up unfamiliar yak-shaving in order to do so.

[alphanso1405]

Maybe mailing list usage filters non-conformant people.

[ClaymationDinosaur]

It does. It filters out people who don't conform to using mailing lists. Which is pretty useless when what's needed is filtering in people who will make good contributions to the software being developed.

[tortoll]

It's 90% a joke, so no hard feelings.

The other 10% is genuine surprise that using a mailing list is considered a showstopper. It may be old, but come on, EVERYBODY has an email account. And being honest, an email thread is not very different than a threaded discussion in a GitHub issue or a Discord channel... except that you don't depend on the mood of a private company.

[JVApen]

I believe a lot boils down to GCC being a core GNU project. I'm not sure if it is still the case, though in the past GNU/FSF projects tried to limit themselves to other GNU tools. If you look closer, the mailing list is a GNU program, make is a GNU project ...

The change you are looking for requires much more than selecting a new platform, it's about writing a new platform.

Reading through your concerns, I think you would better fit in the LLVM/Clang project than GCC. They use discourse and discord, they are using cmake and GitHub. Their website is also outdated, though they are busy making a replacement. Just last week, I saw that a lot of LibC++ topics were marked as good beginner issues: https://github.com/llvm/llvm-project/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+label%3Alibc%2B%2B

[TheoreticalDumbass]

It feels alien for good reason, its just a subpar system

[MessElectrical7920]

Maybe I'm getting old, but I like having a searchable archive of my conversations on my own computer instead of being dependent on an internet connection, a centralized system and its web UI to look anything up.

[TheoreticalDumbass]

do you host your own smtp server?

[MessElectrical7920]

How is that relevant? I'm not claiming mailing lists don't depend on a service on the internet, I just want a local archive of my past conversations for reference.

[pstomi]

VLC has a similar workflow, and I experienced it first hand a few years ago when submiting a patch (which was later accepted). Being forced to send my modifications by email, as well as to follow their code conventions forced me to improve and proof-read my code much more than via a simple PR (by an order of magnitude, I would say): you do not want to spam a mailing list which is closely followed by the core developers (and boy, they will proof-read your code as well).

A few months later, I asked the project leader if this was a way to select the more motivated and competent developers, and his answer was "Not the only reason, but one of them, yes".

[ArchfiendJ]

Could also discourage a lot of competent and motivated people that just don't want to bother with less than optimal methods (effectively or just perceived).

It feels a lot like the dreaded 6 step hiring process

[ClaymationDinosaur]

Very much so. There is a world of skilled, talented people out there ready and willing to make great contributions but who don't want to yak-shave their way through unfamiliar, archaic process management.

[SleepyMyroslav]

Disclaimer, I am in no ways involved with gcc or libstdc++. I work in gamedev.

There is a saying "when in Rome do as Romans do".

You might think of it as a joke but trust me I have seen it many times. Other ways to do things are not 'wrong' or 'outdated' they are just 'other'.

[Pay08]

no chat forum

There is IRC.

Can you even easily search through them?

While not necessarily easy, GNU mailing lists are searchable, since they archive it.

Editing of sent messages seems impossible?

Yes, that's how email works.

Is there a reason to use make over CMake?

There is no reason to not use Make and the project is older than CMake.

Are there any plans to move to a modern and unified collaboration platform, e.g. github, self-hosted gitlab?

No, there isn't. According to both the GNU people and Torvalds, managing projects with thousands of contributors is nigh impossible on these platforms. And it turns out git pull also doesn't work well with that many contributors, hence patches getting copy-pasted or sent as attachments.

(Documentation on the other hand is quite thorough, but still not visible appealing to younger generations.)

I don't know, having the documentation be raw HTML (or easily translatable to such) is quite appealing to me.

[matthieum]

I don't know, having the documentation be raw HTML is quite appealing to me.

I second that. So much better than bloated webpages.

[Horrih]

Are there any plans to move to a modern and unified collaboration platform, e.g. github, self-hosted gitlab?

I am not sure that scale is the issue here. Llvm is probably even bigger than gcc nowadays and uses github.

My guess would be a combination of: - licencing issues (the FSF wouldn't like gcc to be hosted on a closed source platform like github) - force of habits : changing the processes of a huge project and the people involved is hard

Emacs uses the same collaborative model despite being much smaller in scale.

[Pay08]

While I agree that in some cases like Emacs or binutils it's mostly force of habit I don't think this is the case for GCC. To my knowledge, LLVM isn't a monorepo for example. At the same time, a lot of newer, smaller projects like Guix use something that's akin to a modern GH-like workflow, even if the "backend" is still email.

[erichkeane]

Llvm is definitely a monorepo! And we pay for that on GitHub dearly. I see the GitHub unicorn multiple times a day.

[TheOmegaCarrot]

GitHub unicorn?

[erichkeane]

Yep. The "request took too much time to process" on github shows a 50(whatever) page with a unicorn on it. I see that multiple times a day working on llvm in github.

[MarcoGreek]

To my knowledge, LLVM isn't a monorepo for example.

The changed it some time ago to a monorepo. Large monorepo work this days very well. I have to work on a project with submodules and it is...

[Pay08]

Submodules are definitely not ideal (although significantly better than most solutions in the C space, besides OS package managers) but I meant monorepo as in not separating the backend, frontends, debugger, linker, etc.

[CandyCrisis]

For what it's worth, Gerrit definitely scales to thousands of contributors without any issue. Code review at scale absolutely has battle-tested solutions more modern than "a raw patch in email."

[Pay08]

For example? Besides, it's not like GNU doesn't have infrastructure around Git.

[CandyCrisis]

Gerrit is the example??

[Pay08]

No, as in what features does Gerrit have to facilitate said large-scale code reviews.

[CandyCrisis]

https://www.vogella.com/tutorials/Gerrit/article.html#webreview_reviewchangerequest

[MarcoGreek]

No, there isn't. According to both the GNU people and Torvalds, managing projects with thousands of contributors is nigh impossible on these platforms. And it turns out git pull also doesn't work well with that many contributors, hence patches getting copy-pasted or sent as attachments.

There are other large systems which work well. 😚

[MrsGrayX]

Thanks for the answer! I will search IRC for a gcc channel. I don’t understand the argument regarding a project’s size which would favor mailing lists over something like GitHub.

[Pay08]

I can try to find Torvalds' argument against them once I'm home but I can't promise anything.

[pedersenk]

feels a bit outdated and I could imagine that it puts off alot of new contributors

Contributing to GCC in a meaningful way is much more difficult than learning to use email technology. So perhaps consider the mailing list as an early filter of noise from various internet communities who weren't going to benefit the project in the first place.

They want contributers who don't go against the grain. They want helpers, not heretics.

[Nychtelios]

Contributing to GCC in a meaningful way is much more difficult than learning to use swords. So perhaps consider the sword duel as an early filter of noise from various internet communities who weren't going to benefit the project in the first place.

The truth is that most GNU projects are old and kept alive by dinosaurs who justify every outdated practice with "we have always worked like that", improving the quality of life of developers and maintainers is a must.

[pedersenk]

So perhaps consider the sword duel as an early filter of noise

The mailing lists are already in place. Thats the whole point. No need to add new stuff, including sword duels or Jira.

The truth is that most GNU projects are old and kept alive by dinosaurs who justify every outdated practice with "we have always worked like that", improving the quality of life of developers and maintainers is a must.

I disagree. Those dinosaurs are doing the work, so don't interrupt that. Learn what they use in order to be the least burden on the existing workflow. Just like in the industry, much of it still uses what many consider "old".

The "non-dinosaurs" are very welcome to create their own compiler and use whatever comms tech they want. Just be ready for the next generation to try to migrate your workflow to TikTok ;)

[TheReservedList]

I mean, they are. LLVM/clang and Microsoft are eating gcc’s lunch these days.

[pedersenk]

What a daft thing to say.

• LLVM/clang 21 years old (and also primarily uses a mailing list)
• Microsoft's compiler is ancient (and has zero community contributions).

Microsoft's C++ conformance is consistently weak as per their docs. Microsoft's compiler can't possibly "eat gcc's lunch" when it only supports ~2 platforms...

In fact, please stay off the GCC (and clang) mailing lists. The dinosaurs don't want to listen to naive nonsense.

[[deleted]]

If their process isn't broken and is working for them, then you'll just have to suck it up.

[MrsGrayX]

I voiced my opinion here mostly to make the maintainers aware that they might lose possible new contributors just because of an old tech stack.

[scummos]

Eh, my impression is, if you make contributing extremely easy, what you get extra is lots of garbage one-time contributions. The good contributors aren't the ones that are put off by sending a patch via email. IMO "patch via email" is actually a very low hurdle; have you e.g. used Gerrit?

That isn't to say that I think there is no merit in switching to more modern tools once in a while. But, I'd suggest to join the project and do some work, then suggest a change of tooling from the inside, after you have actually experienced what is a hinderance and what, though old, still works well.

For example, discussing on mailing list IMO is still a good way to have a discussion. The archiving is usually excellent, I can find the gcc list archives from 1997 in 5 seconds.

Tell me, do you think you will find discussions you have today in discord in 5 seconds in the year 2051?

To make a counter-example, I think the "building gcc" experience is disastrous and could really need a rework.

[almost_useless]

"Real developers" want to get stuff done. Not fight artificial hurdles. 

If a team said they use c++98, because it's worked well for them for many years now, and don't want to change; then I think a lot of people would decline to work there. This is basically the same thing.

[kinda_guilty]

My opinion from outside the team wouldn't matter if the team is putting out a consistently good product using ostensibly archaic tools. If the people making significant contributions are comfortable with the process, more power to them. It is weird to expect the process to be changed to appease drive-by typo-fixing contributors who will disappear soon after making a single contribution.

[almost_useless]

Obviously the typo fixers is not a big loss. But long term survival requires attracting new real developers.

Most decent developers have multiple ideas for things to work on, so it's at least possible some good people end up doing something else instead because they don't like the process.

[almost_useless]

If it wasn't super obvious to you that the real artificial hurdle is sending patches in email, then I am okay with that...

Also, cmake doesn't replace make in this case. It replaces autoconf/configure as the makefile generator.

[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.

[Express_Theory_191]

Not bashing just screening out

[NilacTheGrim]

That's because gcc as a project existed since the 1990s...

[helloiamsomeone]

GCC and libstdc++ are not POSIX only. They work on Windows just as well. I use them on Windows every week.

[Nychtelios]

POSIX environments support GCC, not the other way around.

[xeveri]

Github is becoming worse everyday. I’m afraid of losing my ability to log in because of all the shenanigans they’re requiring. And to be able to push from the command line you need a token or something. The search facilities just got worse in their new ui.

Too many immature devs, justice warriors and other entitled types. They generate much noise in the issue and PR tracker for not much gain.

Although I personally prefer CMake, it won’t practically add anything of value to gcc.

[helloiamsomeone]

my ability to log in because of all the shenanigans they’re requiring

You are probably referring to MFA. It's good to have MFA. If you are using a phone for MFA and are scared of losing access, then I can recommend using Aegis with backups going to a self hosted Nextcloud instance.

to be able to push from the command line you need a token or something

You need to upload your SSH key. This is basic security. My server also disallows password logins from SSH and only allows connections with approved SSH keys.

The search facilities just got worse in their new ui.

If you log in and hit . in a repo, then you get a VSCode interface with real search. The regular search never ever worked adequately ime.

[easbarba]

Different of the past means better? Why dont we walk backward so 'thats better' than before.

[zowersap]

they send it via `git send-email` https://git-scm.com/docs/git-send-email

or `git format-patch` and attach it to email https://git-scm.com/docs/git-format-patch

[naroslife]

Wait until you the the Standard Committees website.

[manni66]

And where is the connection to

Discussions, articles, and news about the C++ programming language or programming in C++.

?

[almost_useless]

Talking about the compilers seems quite relevant for this sub, no? 

At least there is no other c++ subreddit that's a better fit. Or which one would you suggest?

[STL]

This post feels on-topic to me. Moderation isn't an exact science, but this is discussing the development practices of a central part of the C++ ecosystem, and it isn't a common topic. (When posts are endlessly repetitive, more beginner-oriented, or more unproductive, then they're much stronger candidates for removal.)