The State of Toolchains in OpenBSD | Hacker News Reader

The State of Toolchains in OpenBSD

cambus.net

58 pointsfcambus21 comments

Open articleView on HN

> The main reason has to be newer C and C++ standards support.

Ironically clang is now behind gcc and VC++ regarding newer ISO C++ support.

https://en.cppreference.com/w/cpp/compiler_support

The licence mailthread in the LLVM list (pointed to in the article) is brutal.

Moving to a licence otherwise deprecated is a huge deal. For a "no compromise" community (OpenBSD), its huge++

But, the pragmatism appears useful: without this, modern hardware cannot be compiled to optimally. It was a least-worst choice decision.

If LLVM is now not a blocker, I wonder if they'll be able to start using Rust for development. At least as an experiment.

Rust's inability to compile itself on 32-bit machines was a blocker given the all OpenBSD supported platforms are self-hosted and releases must be built using the base system compiler on real hardware. No cross-compilation, no emulators. requirement.

Ooooo... that's right. I was reading about a related issue with (IIRC) Rust v1.51 on some 32-bit platform where they were running out of memory.

Never mind how long that would take.

Why was the compromise made for LLVM 10 with the Apache license and not for GCC with the v3 GPL license?

Probably because of the drm code requirements and only having a choice between GPL v3 (gcc) or Apache 2 (llvm).

I would imagine that many or most (or all?) OpenBSD developers consider the Apache license less than ideal but GPLv3 counterproductive or even malicious. Not a tough choice from that perspective. I'm not advocating for or against anything, just stating common reasoning amongst BSD folks.

No compromise, AFAIU. They felt they had no choice but to upgrade to a more modern compiler, and they preferred clang+APL2 over gcc+GPLv3. Apache 2.0 still violates their licensing policy. Technically, GPLv2 also violated their licensing policy. They historically used GPL'd software like gcc when there were no viable alternatives and doing without wasn't acceptable either.

EDIT: See https://marc.info/?l=openbsd-misc&m=159514079929237&w=2

I'm curious whether it would be okay to optionally support other toolchains. For example, if openbsd works when built with GCC 4.x but also can build with GCC 10.x, it remains "safe" with the older GPLv2 GCC but a person wanting performance could opt to use the latest version. Or is that tempting a slippery slope?

Well try it, that's the good stuff with bsd's, keep your base-system clean and just compile the ports with gcc. Your system will still always boot.

something like that (but gcc instead of clang) in your make.conf:

CC=clang11

CXX=clang++11

CPP=clang-cpp11

I just reviewed 2 m68k patches to LLVM today; I expect we should be able to build the m68k port of the Linux kernel with LLVM soon.

I hope they will do the transition from CVS too.

Dunno about "soon", but I'd assumed that was the ultimate goal of Got (https://gameoftrees.org/)

There may be OpenBSD devs working on and using Got, but the OpenBSD project has never declared that it intends to move to it.

Sorry for a long answer to a one-liner. Whatever people's opinion about what they should use... CVS works for them, everyone of their users and developers is used to it, and they've been self hosting their code for ... 15 years at this point... 20 years? Even more? How many projects can actually say that?

Using OpenBSD for servers at times their use of CVS has never been an issue for me. So I get it, it's not the newest tool around, but if it works, is understood, maybe there's no immediate need to switch? The same crowd which says "they should just use git already", would probably follow up with "and how come perl is part of the base system and the pkg manager is written in it?... could we get Rust into the kernel while we're at it?"

OpenBSD's conservatism is what makes the system so immensely well documented, vetted, therefore secure and easy to use. They may switch at some point, and if they do it will be swift, and done right. But if I think about it: as a user I don't really care. It's not a huge deal to me what they're using for source control.

I agree. They had a project, OpenCVS, to rewrite CVS. It was eventually abandoned - apparently the team felt the gain wasn’t worth the effort.

For a tightly knit team working with a central repository, CVS is just fine. Moving Python from CVS to SVN to Hg to Git gained nothing and made the development process so complicated that it was necessary to introduce even more complication by scripting it.

It's fine because current developers are satisfied, but possibly some new developers (candidates) don't want to treat CVS. Still it's fine if current developer think it's not a problem.

I'm not so sure. I think it's really questionable if the SCM used is a major factor in deciding what open source project one wants to contribute to? "I would want to contribute to OpenBSD, but they use CVS, so I won't" - really? o_O

I get that github is probably the "lowest barrier to entry" here, but providing the "lowest barrier" is probably not even in OpenBSD's interest here. It's the same with some operating systems not providing graphical installers and whatnot. I could see not using github in a similar light here. If it's a simple bug fix or a one line change, reporting it is sufficient, a dev will fix it. If one's engagement is supposed to go much further, I don't think CVS is such a big hurdle? Or am I misjudging here?

I'd really find it hard to believe. When I was contributing to OpenBSD (in a tiny way) my attitude was I want to help the project, to do something useful. So I read on everything relevant, made the best effort to do everything right, asked around on mailing lists, and in the end my contributions were approved. I can't imagine anyone in this situation saying "CVS? I don't like it, so I give up."

Also, practically speaking, CVS is trivial to use, you can learn whatever you need in 5 minutes and never think about it.

I hear that all the time "oh it's using cvs and not git??...that's bad!", i then instantly know that this is a person who is not able to learn other tools.

BTW: Those rust, git enthusiast are those who never work on the project in the end, the are evangelists not makers.

Reply on news.ycombinator.com