Hacker News Reader

Comment by angersock | Hacker News Reader

"2. PLEASE use a standard configure/make/make install method for your language, and don't write one yourself or depend on some backwards antiquated build tool that nobody uses. Interpreted languages often have their own standard, and compiled languages often use autoconf/automake. Learn them and use them, or at the very least, make an incredibly basic Makefile. And please document the expected permissions and users (chowns/chgrps/chmods)."

This, a thousand times this.

A basic Makefile is always preferable to me finding a problem with your magical unicorn make system of choice (read: CMake).

View on HN

The problem is that make and all make-based systems that do anything non-trivial (e.g: code generation) are terrible. They all do dependency graph computation prior to starting building, which in the case of code generation + dependency scanning is simply wrong. They all become painful with complexity. They all end up with false negatives, where you have to "make clean" to continue working reliably. They cannot pass parameters to sub-targets in order to build the same target in slightly different ways for different contexts (e.g: Unit tests vs system).

And yet, for all that, they've worked for 30 years.

For some value of "worked", in which people generally have to "make clean" every now and then, have false negatives that cause crpytic bugs now and then.

Not to mention auto-generated code being extremely difficult to work with.

All companies I worked at had replaced "make" with something in-house, because make is simply horrible.

cmake is standard enough now that 'magical unicorn' is rather unfair. I've had more difficulty with bare/automake makefile-based systems than with cmake (not that cmake is at all stellar: but it can at least handle spaces in filenames).

However, CMake sucks in terms of installation paths. Ever tried installing a library into a libdir other than ${prefix}/lib? In the worst case, the developer tries to "fix" this by guessing the architecture and append a magical 64. This works on some distributions but of course not all of them.

I got sick and tired of this situation and wrote a small CMake module [1] that accepts standard configure options to determine the installation path.

[1] http://bloerg.net/2013/10/29/turning-cmake-into-a-good-unix-...

For other cmake writers out there, this isn't hard.

    set(LIBDIR lib CACHE STRING "lib dir")
    install(${lib_targets} DESTINATION ${LIBDIR})

That's what I do and I am able to build packages with it just fine, that send the libs to wherever the hell they want them.

I am not saying it is hard, I just wanted to point out that CMake does not provide something like this out of the box. Quite the contrary, now every developer has to re-invent this tiny wheel, and I've seen this going wrong several times.

Not sure where the cut off is or should be, but it doesn't feel standard to me.

On my anecdotal desktop install there are two packages that use cmake; awesome and taskwarrior.

Grep'ing the ebuilds on this Gentoo box, shows me ~400 packages out of ~16000 that use cmake(excluding KDE where it clearly is standard). A lot of the remaining ones seem to be very project specific too(70 leechcraft, 11 fcitx, 10 opensync).

Grepping the PKGBUILDs on Arch looks quite a bit different

Official: 547 out of 5115 use cmake.

Unofficial: 5167 out of 47069 use cmake.

A lot of these offer plain Makefiles too, but cmake is decently popular and hard to dismiss.

For me it's not really about difficulty, it's about extra time. Is it going to take me extra time to find, download, install, and learn how to use your unusual build tool? If so, that sucks. Using the most standard/common build tools saves packagers headaches.

Autoconf/Automake are more popular so it's going to be a lot easier on packagers if developers use them. But if they use them incorrectly, packagers will have to hack on the Makefiles when they could have run a bootstrapper like autoreconf.

Reply on news.ycombinator.com