Hacker News Reader

Comment by soulcutter | Hacker News Reader

Over 10 years later, and this is still relevant. It's scary how entrenched 'good enough' solutions become.

It's also kind of amazing how terrible most of the replacements people developed are. Some are significntly worse than autotools, which is no mean feat.

I blame make's awful syntax.

Yes! But I'm not so sure we can entirely blame the make syntax. Something made the CMake people believe that inventing a new macro language / m4-redux was a good idea. I'm thinking that either m4 is a mind-virus or they're serving wine in lead glasses at the annual build-system conferences.

Or; a build system is harder than it seems.

Makefiles work fine in the trivial case, the problem is that things quickly become complex. Automating that complexity seems like it should be easy but, as it turns out, it isn't.

Is there something about the (admittedly very difficult and thankless) task of automating builds that justifies re-inventing the wagon-wheel of languages? Because that was my specific complaint, and there's a reason why it was specific.

Because it seems easy. And easy things done "wrong" require re-invention.

There should be a way to $FOO. Well, there's a way to do it in a Makefile but figuring that out is harder than should be, and doesn't make sense when you finally do figure it out.

"Well that way is stupid. Here's how I'd do it:"

CMake started for needing a suitable build system for a medical visualization application[0][1] that Kitware was working on, iiuc. How they could be using Tcl (an established, purpose built embeddable scripting/control language) in the Insight project, come to the conclusion they need a custom build system, and then when it comes to a control language decide to roll their own is a mystery to me, and a dropped ball, as far as I'm concerned.

I like cmake, and used to use it exclusively, but after running into so many issues with their homebrew scripting/configuration language, I've mostly moved on. I wouldn't be surprised if I end up coming back, and I'd encourage everybody to give it a shot (the ease of typical simple Makefile generation, but with extra muscle), but the omission of Tcl as a control/config tool has always baffled me.

  [0] http://en.wikipedia.org/wiki/CMake#History
  [1] http://en.wikipedia.org/wiki/Insight_Segmentation_and_Registration_Toolkit

edit: formatting

s/Some/All/

I hate using autotools, but every time I touch a project that uses something else (and that is too complex for a ten-line Makefile), I inevitably end up wishing that it used autotools. I suppose it shows that sometimes a few decades of polishing a turd does sort of work.

what's about cmake?

CMake is interesting because the CMakefiles are just a different type of editable/configurable build script (ie. slightly different Makefiles). It's still an interpreted step between build instructions and the output that you actually use to build which isn't meant to be edited and therefore obfuscates part of the process... so autoconf. This is both a strength and weakness in that there are so many external modules for CMake (eg. the various FindX) that they work great most of the time but when they break they are more difficult to fix than an atomic change to the actual compiler flags in a Makefile.

I don't think there will ever be a standard build tool, simply shunts to get the needed functionality from others. Eventually all build tools will exist in each other and the only interface will be recursion.

CMake has the nice property of being able to generate non-Make build systems, but otherwise is more of just "autotools done differently" rather than "autotools done better". In practice I haven't found it to be any more pleasant to use than autotools.

So far CMake served us well. I'm using it for 8 or so years now for small and larger systems.

I especially like that one file allows me to develop on XCode, somebody else on Visual Studio and finally deploy on Linux/gcc. One config file creates native projects on all 3 platforms, no manual hacking.

Have you tried using cmake on e.g. IRIX?

Yes! A former coworker dug up my old O2 running a 6.5 variant, installed cmake and built BRL-CAD ( http://brlcad.org/ ) with it. Supposedly, it worked quite well (but took a very long time, I believe it was a low end cpu, I want to say 183mhz). Given that I rewrote the build system in 2003 for BRL-CAD to use automake instead of cake, I'm very impressed by cmake.

Most of the so-called modern build tools avoid make entirely, so its syntax cannot be to blame for their miserable quality.

I was thinking more along the lines of if writing for sh and make were less painful, then fewer developers would accept using such awful build systems instead. Autotools included.

I find neither sh nor make particularly painful. Python, however, I cannot stand the sight of.

I don't know about this. Back in 2003 I got all spun up on scons, and later working at Google and their Build system which was pretty amazing in what it could do. At the same time I discovered that you can't run Windows software, PC hardware, and a Windows OS that are skewed by more than a few years (seriously true for games, less true for productivity apps). And yet I can download thttpd and type 'make' in the directory and it just builds.

I've concluded that you can either embrace highly complex evolving systems and build tools which follow that evolution in such a way as to provide functions. Or you can make "point in time" sorts of things that are ephemeral in their ability to do what they do. Not a good choice but the only two that seem to be durable.

I completely agree that it is a challenging place to be.

Reply on news.ycombinator.com