Comment by novas0x2a | Hacker News Reader

Comment by novas0x2a | Hacker News Reader

First, caveat: this is for C++.

I wrote a major part of a complex build system in autoconf[1,2]. I gotta say, just about ANYTHING would be better. There's no abstraction; at no point can you forget you're writing m4sugar (implemented on top of m4) that is writing bourne shell code. There's no indication if you screw up in subtle ways except an sh parse error when you run configure. I've had to run configure with sh -x more times than I can count. EVERY SINGLE autoconf release changes the interface, and there's no reasonable way to detect the autoconf version to work around it. Every autoconf release requires hours of tinkering. Autoconf 2.65 changed the quoting rules for m4_upper and m4_lower; making those work reliably on old and new versions is obnoxious.

I've spent many, many hours working on autoconf code. I consider myself an expert at it. And yet, I'm willing to throw it all away and replace it with ANY build system that isn't a pile of junk. I just haven't found one yet :(

The only ones that rise above the noise are scons, waf, and cmake. (No, I'm not using jam/bjam or ant. DIAF.) CMake does most of what I want, except they invented a completely idiotic new programming language. Waf and CMake both provide me with a system to make a build system instead of a build system itself (screw that). SCons reinvents make... poorly and slowly. Of these, only cmake handles windows without forcing me to sit in front of a windows machine for hours. (Autoconf, obviously, falls over hardcore on windows unless you set up a Unixy build environment on it. Not The Point.)

Anyway, that was a cathartic rant. (No, but seriously. I'm up for more suggestions, or you can try to convince me that my opinions of the above tools are wrong. I really do want to switch away, I just haven't found anything that's a big enough improvement to justify it.)

1) http://github.com/visionworkbench/visionworkbench/tree/maste...

2) http://github.com/visionworkbench/visionworkbench/blob/maste...

CMake is very decent. Yes, they have some sort of language that requires learning, but it's really trivial and the big bonus is that you can write plugins for your own libraries.

It's fairly easy to search and link to third-party libraries. Really, yes, the language is a tad weird, but very simple and frankly it's a small price to pay to have a real cross platform C++ makefile system.

As you said the fact that CMake supports Windows and Visual Studio out of the box is a big plus as well.

CMake also enables you to automatically run unit tests and package your release into a tar.gz or a setup.

Really, we're very, very happy with CMake and the effort we put in it paid off a lot. I really encourage anyone needing cross platform makefiles to check it out.

To sum it up, CMake is a makefile compiler. You write your makefile in "CMake", and it compiles it into a classic Makefile, Visual Studio project, etc.

We've built a decent system here that relies on ant, make, vs_2003, .bat files, and some custom python scripts. It even works on both platforms (windows/redhat)! </sarcasm>

I've played around with CMake also, and I've found it to be the most reasonable. This is especially true if you have a diverse team with members that prefer Emacs/VI or Visual Studio and a project that needs to work natively on multiple platforms. Different people work better in different environments, and there's nothing wrong with that.

It's not perfect, but I find myself saying 'WTF' less when using CMake. I have no idea why they decided to make their own little language, but its syntax is super-simple, and very well documented.

    No, I'm not using jam/bjam or ant. DIAF.

While I'm no fan of xml, I've found ant to actually be quite usable (at least for java projects).

I've used it in several projects so far & although it did require the occasional tinkering it wasn't even close to being as big of a time sink as autotools were.

That's largely because Java aims for cross-platform compatibility. It doesn't have to deal with nearly the rats' nest the autotools do. Note that I still think they suck and would probably use CMake if in the futuer I find myself working on a C or C++ project of any size.

Maintaining OpenSSH's autoconf scripts over many years now, I have found it best just to discard the pretence that autoconf is in any way consistent and treat configure.ac as a Bourne shell script with some macros on top.

My company has been switching to CMake over the past 8 months, and it's not that bad.

Well, not usually.

Their conditional expressions are goofy, it's never clear whether mixing variables and lists will do the right thing, and good luck doing something complex using only documentation. So yes, the CMake language is bad.

But once you write a file, it Just Works. I don't usually need to revisit a CMake file to correct something, unless I'm adding/removing files or dependencies. I never had that feeling with bjam or autoconf - small changes to the code always had a major impact on these build systems. We compile code on both Windows and Linux, so it's the only viable option, and thankfully it's not too bad :)

I really enjoy using premake4, http://industriousone.com/introducing-premake it works on linux, mac and osx. I don't know about AIX/Solaris and have not tried it with a really huge project.

It's been coded in C, is scriptable with lua and that would get around the CMake specific language. It generates the project files for the platforms you want, so it may save you from writing the autoconf files yourself.

Reply on news.ycombinator.com