On: Smart Pointers in (GNU) C

[ReleaseCandidat]

> Why do some people hate Make so much to use an abomination like CMake?

Because Make doesn't work either. This holds for Make too:

> Probably because it looks nice in the tutorial with apparently simple syntax, but then on real projects it devolves into a hundred lines of abstraction nonsense over environment variables and spawning programs.

The real solution is of course using neither (and neither Automake). Pick one (that works for more than C, C++ and Fortran at best) build system and use that. I've choosen Buck 2 https://buck2.build/

https://github.com/Release-Candidate/Cxx-Buck2-vcpkg-Example... https://github.com/Release-Candidate/Cxx-Buck2-Conan-Example...

[fn-mote → ReleaseCandidat]

How about the importane of your build system lasting for a decade or more?

For all the hate about Make, it works just like it used to a decade ago.

[ReleaseCandidat → fn-mote]

> Make, it works just like it used to a decade ago.

So, not at all for anything not simple. It's not that we all got together one day and said "you know what, (GNU) Make does all what we need, let's build some new, more complex, alternatives". Make is fine, until it isn't, which is a point that's easy to reach with C, C++ and Fortran with modules (so, everything after Fortran 77).

And nowadays it's _way_ more homogenous as back in the day when you had all the real Unices with their own compiler and own linker and assembler and way to build and use libraries, in 32 und 64 bit on the same system. Not to forget about the oddball using VMS.

[acuozzo → fn-mote]

Is your deliverable source code or is it a binary?

In my experience, Make (and build scripts) work just fine when your deliverable is a binary. You have complete control of the build environment, so hardcoding e.g., /opt/my/cross/compiler or relying on $PATH is a non-issue.

However, if your deliverable is source code, then you can only make so many assumptions about the build environment. This is where GNU Autotools and CMake shine.