Comment by iforgotpassword

"Sounds complicated. I want it to throw exceptions and have significant whitespace on top of all that complexity!"

My experience with cmake, though dated, is that it's simpler because it simply cannot do what autotools can do.

It really smelled of "oh I can do this better", and you rewrite it, and as part of rewriting it you realise oh, this is why the previous solution was complicated. It's because the problem is actually more complex than I though.

And then of course there's the problem where you need to install on an old release. But the thing you want to install requires a newer cmake (autotools doesn't have this problem because it's self contained). But this is an old system that you cannot upgrade, because the vendor support contract for what the server runs would be invalidated. So now you're down a rabbit hole of trying to get a new version of cmake to build on an unsupported system. Sigh. It's less work to just try to construct `gcc` commands yourself, even for a medium sized project. Either way, this is now your whole day, or whole week.

If only the project had used autotools.

I've seen programs replicate autotools in their Makefiles. That's actually worse. I've also used the old Visual Studio build tooling.

Autotools is terrible, but it's not the worst.

Configure-make is easier to use for someone else. Configuring a cmake based project is slightly harder. In every other conceivable way I agree 100% (until someone can convince me otherwise)

And presumably the measure by which they are judged to be reasonable or not is if they prefer CMake over Autotools, correct? :D

> Why, again, software in the Linux world has to be packaged for multiple distributions?

Because a different distribution is a different operating system. Of course, not all distributions are completely different and you don't necessarily need to make a package for any particular distribution at all. Loads of software runs just fine being extracted into a directory somewhere. That said, you absolutely can use packages for older versions of a distribution in later versions of the same distribution in many cases, same as with Windows.

> And to the boot, you don't have to go through some Microsoft-approved package distribution platform and its approval process: you can, of course, but you don't have to, you can distribute your software by yourself.

This is the same with any Linux distribution I've ever used. It would be a lot of work for a Linux distribution to force you to use some approved distribution platform even if it wanted to.

As michaelmior has already noted, Linux is not an OS. Anyone is free to take the sources and do as they wish (modulo GPL), which is what a lot of people did. Those people owe you nothing.

But consider FreeBSD. Contrary to Linux, it is a full, standalone operating system, just like Windows or macOS. It has pretty decent compatibility guarantees for each major release (~5 years of support). It also has an even more liberal license (it boils down to "do as you wish but give us credit").

Consider macOS. Apple keeps supporting 7yro hardware with new releases, and even after that keeps the security patches flowing for a while. Yet still, they regularly cull backwards compatibility to keep moving forward (e.g. ending support for 32-bit Intel executables to pave the way for Arm64).

Windows is the outlier here. Microsoft is putting insane amounts of effort into maintaining backwards compatibility, and they are able to do so only because of their unique market position.

> On the Windows side, if you make installer for Windows 7, it will still work on Windows 11.

Do you speak from experience or from anecdotes ?

Yeah I've had specific use cases when I need to use syscall. I mean... if there weren't use cases for syscall then it wouldn't exist.

But not only is syscall an example of portability done wrong for APIs, as I said it's also an example of it being implemented in a dumb way causing needless work and breakage.

Syscall as implementation leads by bad example because it's the only method Go supports.

Checking for GOARCH+GOOS tuple equality for portable code is a known anti pattern, for reasons I've said and other ones, that Go still decided to go with.

But yeah, autotools scripts often check for way more things than actually matter. Often because people copy paste configure.ac from another project without trimming.