Hacker News Reader

Comment by joepvd | Hacker News Reader

This is awesome. Have just been strugglingh to get started with this the past few evenings. Will take this as my guide. Thanks for posting!

BTW, good place to start learning the relevant parts of GCC?

View on HN

If youre just starting something and not maintaining something older you should really take a look into CMake

Thanks for your recommendation!

Yes, I am just starting something small and new. And am now jumping the cliff of learning C, gcc, make, autotools, and gnulib-tool, of course all at the same time. Talking about a heap overflow ;)

Is it correct that CMake is a replacement for GNU Make? So far, GNU Make has not posed a problem. Can CMake assume some roles of the other tools as well? I am looking to have this interesting ride a little less bumpy.

CMake does not take the place of GNU Make. It just generates your makefiles (or project files) for you. It handles all the hard parts, you just tell it what the files, libraries, and options you want are and it generates everything for you.

Here is an example project using CMake that is targeted for a MSP430 https://github.com/mpiannucci/HelloMSP430

CMake and GNU Make have only the word 'Make' in common, CMake is an automatic build tool while the GNU Make is just a GNU version of plain old make tool. CMake is there to prepare a proper Makefile for the "GNU Make" to consume.

I'm pretty baffled that people recommend CMake so often. I looked into it, and found:

* The worst scripting language ever, seemingly made by someone without even basic theoretical knowledge of language parsing. It's even worse than shell scripting.

* The same I-don't-care copypasta culture most autotools users seem to follow, but the free documentation was even worse (or at least back when I tried it). There's a book which I didn't have access to, though.

* Less enduser/packager friendly, with worse help texts, documentation, and features (seems to have caught up somewhat). Plus, everybody already knows how configure scripts work.

* The portability to Windows in reality means lots of if(WIN32) branches.

* The results are often brittle. This is also true of autotools in practice, but at least there is some info out there about how to write autoconf macros correctly. Even the .cmake files that ship with CMake seemed to be thrown together carelessly the last time I looked.

* Also, CMakeLists.txt must be the worst filename for a script I've ever seen. I'm only half serious on that one. I know it doesn't matter, but it bothers me terribly. It's ugly and misleading and makes me question the author's sense of aesthetics and basic competence.

CMake is terrible. Autotools is also terrible, but at least it's got an excuse. Just learn your damn tools. The real problem with autoconf is that nobody wants to invest any time learning about their build system and instead just copy-pastes it around, creating a brittle mess. From the CMake projects I've seen, it doesn't really solve this problem at all, creating a similar mess. And now your users have to install CMake and figure out how it works, and it doesn't even print a useful --help text.

Appreciate your opinion. Have been looking into CMake this evening, and my little impression was that it does not make the problem smaller, just different. The things I have been searching for, also did not yield that much high quality answers. Think I will stick to learn autotools enough, as that might come in more handy in general.

Managing seperate build files for each platform sucks, especially on big projects. Thats where CMake is useful to me. It simplifies a lot for our company, but to each his own.

Agree that CMakeLists.txt is a terrible build script name though haha

Reply on news.ycombinator.com