Hacker News Reader

Comment by Davidbrcz | Hacker News Reader

Just use cmake or scons. In 2016, you should not hand write a single makefile !

A simple cmake/sconcs build file will be as simple as the one shown (or even simpler !) and it will definitively will be easier to integrate external dependencies if you have to.

View on HN

Please do not use scons in your projects. Poorly written SConstructs are as common as poorly written Makefiles, and are more difficult to patch to work correctly because of all the magic that goes on under the hood.

SCons has many issues that negatively affect packagers. Some are listed on the Gentoo wiki here: https://wiki.gentoo.org/wiki/SCons

As an OpenBSD packager, I hit many of those issues and a few more. For example, scons’s C preprocessor support is not great, and often brings in header dependencies that should be #ifdef'd out; when those unnecessary headers are removed during build (happens often on a machine bulk building packages), the build breaks.

I’ve replaced SConstructs with Makefiles before. Typically it makes the build faster, simpler, and more portable, and is popular with other OS packagers. Example: https://github.com/sinamas/gambatte/pull/6

Honestly cmake is such a shitty language though. Scons is slow.

CMake is almost great, but I have no idea why they went ahead and designed the _language_ the way they did. (Lists are concatenated strings, everything is basically macro expanded, etc..) I mean, if they were trying to improve on m4 and shell script, I wouldn't exactly say they succeeded.

I realize that CMake has better cross-platform support, but I can't stand using it. For small projects it's fine, but for medium- to large-sized projects it's a bigger headache than autotools imho.

(That said, I explicitly don't care about Windows support, which is the only place where it really matters to have something different than autotools, and even that is not so bad with MingW and will be even better, it seems, with the coming "linux-compatible subsystem")

cmake generally works great, but the larger and more complex the project gets (and the more platforms you need to support), it gets exponentially uglier. I've had the displeasure of needing to maintain a single cmake infrastructure for a large (~500K or so lines plus 3rd party libs) project that targeted Windows, Linux, Mac, iOS, Android, and a few other obscure mobile platforms. Here was the progression:

1. Linux target: "Wow this is a breeze!"

2. Mac target: "Ahh, a little learning curve, but no problem!"

3. Windows/VC target: "Jeez, I hope I don't have to hand-edit this monstrous vcproj this thing generates..."

4. iOS: "WTF!! Simulator targets, device targets, provisioning profiles, code signing.. This stuff was all just hacked into cmake and barely made to work wasn't it??"

5. Android+NDK: "Kill me now"

6. Other obscure mobile targets with toolchains themselves that barely worked: "La La La, I'm ready for the funny farm. The cucumbers! They're dancing! And glowing!! The room is getting hazy and dark.. Where's my vodka?"

Would you write an article detailing your experience?

It sounds fun to read.

Honestly, I don't think I could afford the therapy that I would need to re-live that part of my career in the detail that it would take to do a proper write-up. To this day, I still have no idea how an Android project actually winds up getting built, and their build system philosophy seems to boil down to "keep adding layers of magic, each making lower levels of magic harder to hand-edit and understand".

Most of the difficulty to be honest was with: 1. third party libraries, and 2 the Android NDK.

For third party libraries, every one was slightly different in some frustrating way. Some of them used bog-standard makefiles (thank you, third party developers who do this!), so they basically just worked. Some of them used autoconf/automake, which makes me sad but you can generally get cmake to mate successfully with them. Some of them helpfully had their own CMakeLists.txt, which would build the library, but invariably could never be successfully integrated into a larger project. Some non-open-source libraries came with just one platform's build support, so you'd have to hand-build CMake support for them, and guess which files actually needed to be built/linked. Some of them cleverly generated some of their own source files during the build process ("This is fun to maintain" said nobody ever).

The Android NDK seems to be some Googler's frankenstein hobby project that got accidentally electrified into life and set loose on the world. Like Donald Trump, the NDK is kind of an embarrassing offshoot from the "mainstream Android development story," one that Google would like to pretend doesn't exists. They, in fact, tell you in their docs "Yea, you can use native C and C++ to write Android apps with this thing, but you really shouldn't!" [1] Seriously, their "Getting Started" guide spends a paragraph or so trying to convince you not to get started. Convincing Google's own development tools to build C++/NDK is pretty frustrating itself, so you can imagine how difficult it is to convince cmake to do it.

In short, if you are working on a project that targets desktop, embedded, and mobile platforms and has lots of third party code, and one day that little voice in your head starts saying "Hey we waste a lot of time maintaining separate Makefile, .xcodeproj, .vcproj, etc. Why don't we switch to a single glorious build system that lets us list our source files in one place!?" IGNORE THAT VOICE. Go play some foosball, fix a few bugs, have a cup of coffee, but by no means try to use cmake for this.

1: https://developer.android.com/ndk/guides/index.html

Absolutely crazy.

Thanks for the write up.

I've had a similar experience getting shit to work on multiple platforms. I decided not to use cmake for mobile targets. While the NDK in general sucks to build, if you follow certain patterns you can get a system that works and is fairly straightforward. The path to get there is not easy though, I'll give you that.

That is just kicking the can further down the road. Now, instead of mantaining makefile for make, you are mantaining CMakeLists.txt for cmake.

I use CMake for everything-that-isn't-$work-now because that's the only thing CLion supports. Even at work I've taken to creating my own CMakeLists.txt so I can get CLion support. I like the IDE that much.

It's not perfect, as others have touched on. But it overall satisfies my requirements and I can usually get things done with it.

Being a Google employee, I'm somewhat partial to Bazel (https://bazel.io/) which is based on what we use internally. I've started to ponder what it would take to write a CMakeLists.txt generator for it.

Prr cmake and scons are dog slow. Make isn't exactly fast either. I didn't realise how slow they were until I used QBS which is so fast you sometimes think it hasn't done anything.

Would be nice if you could give an example, not just "use that".

Especially since scons and cmake are in no way easy to learn, imho.

Still easier than make...

hello.c in a directory

make hello

Easier?

cmake is arguably easier to learn than make

and I argue with your conclusion.

Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects.

I mean, a "hello world" CMakeLists.txt can be literally just this:

    add_executable(hello hello.c)

And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.

I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be:

    all: hello

That's not really complicated either.

Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.

When evaluating build systems, one of my major questions is: How much "magic" will I have to work-around in order to do something off the beaten path that the build system's developers never considered?

This is a good criteria for languages as well.

The thing is that these are not equivalent hello worlds. I mean, if only for the fact that the cmake example does proper header dependency management, which is essential to correctly compiling c/c++ code as it changes. It's not something you can leave out of a makefile and still call it correct.

`scons` is very easy to start with:

    Program("main", ["main.cpp"])

The problems start once you want configure stages, build directories, portability and install targets, as all of those aspects are extremely lackluster and incomplete in `scons` and you have to reinvent large parts of the build system yourself essentially for anything even mildly complex.

`cmake` is much better. The language itself is ugly and takes some getting used to, so it's a little more complicated to get started with then `scons`. `cmake` generating `Makefile`s instead of actually building the project itself also adds a layer of complexity. But once you understand the basics it's much easier to get a fully functioning build going, including configure stages, build directories, portability and all that, as cmake has all of that integrated and working right out of the box.

`cmake` feels like a complete build system, while `scons` feels like a good start for a build system that was abandoned at the halfway point.

I still use plain `make` for some Python projects (mostly .PHONY targets to run `pylint`, `autopep` and friends), but for everything that needs to get compiled `cmake` is much easier to use than plain `make`, as you don't need to reinvent a build system yourself, it already comes with almost everything you need.

https://cmake.org/examples/

$ ls src

demo.cxx demo_b.cxx CMakeLists.txt

$ cat src/CMakeLists.txt

cmake_minimum_required (VERSION 2.8.11)

project (HELLO)

add_executable (helloDemo demo.cxx demo_b.cxx)

$ mkdir bin

$ cd bin

$ cmake ../src

SNIP

$ make