Build systems, anyone?

n0stradamus · 2011-12-19 15:20:55

I've recently come to the point where maintaining a Makefile by hand is quite tedious, so I looked around at the several build systems available.
I read a little about GNU autotools, then CMAKE, qmake and finally premake.

Of all these, I find premake to be the most straightforward solution. My project is simple and so is premake. Which of these systems do you use (If i didn't name it, please do so^^)? Have you got reasons to prefer one over the other?

Looking forward to your answers!

lunar · 2011-12-19 16:26:29

I'm using CMake, and I'd recommend this for any ordinary C- or C++ project. Not that CMake it particularly excellent, on the contrary, it's configuration language is rather awkward. But it supports many libraries and tools out of the box, and has a huge user base. Thus for standard project, CMake gives you simple solutions and few bugs, basically because for simple scenarios all the typical problems have already been solved and all the bugs been discovered and fixed by others that also did a standard project.

Last edited by lunar (2011-12-19 16:34:13)

/dev/zero · 2011-12-19 19:30:24

Did you search the forums? This thread already dealt with the same topic.

bernarcher · 2011-12-20 11:24:24

~~Karol~~/dev/zero is (partly) right. This has been discussed before.

But because the thread he linked to appears to be solved, I'll leave this one open for now in case some more fruitful discussion will evolve.

Edit: I am so used to karol reporting stuff. Sorry, /dev/zero, and thanks to karol for setting things straight.

Last edited by bernarcher (2011-12-20 12:32:46)

n0stradamus · 2011-12-20 13:53:42

/dev/zero wrote:

Did you search the forums? This thread already dealt with the same topic.

Yep, I did, but somehow I seem to have overlooked that one. The thread you linked to answers my question, thanks.

redguardtoo · 2011-12-21 07:48:33

lunar wrote:

I'm using CMake, and I'd recommend this for any ordinary C- or C++ project. Not that CMake it particularly excellent, on the contrary, it's configuration language is rather awkward. But it supports many libraries and tools out of the box, and has a huge user base. Thus for standard project, CMake gives you simple solutions and few bugs, basically because for simple scenarios all the typical problems have already been solved and all the bugs been discovered and fixed b others that also did a standard project.

CMake is the second best tool I met (the top one is of course git) during my life.

I don't agree with you that it's configuration lanuage is awkward, though (consider those xml based DSL and syntax of make, autotools,m4, bjam, scon ...?).

Last edited by redguardtoo (2011-12-21 07:52:38)

redguardtoo · 2011-12-21 07:54:39

n0stradamus wrote:

/dev/zero wrote:
Did you search the forums? This thread already dealt with the same topic.
Yep, I did, but somehow I seem to have overlooked that one. The thread you linked to answers my question, thanks.

Autotools would be your nightmare. I used autotools in a big project. It's hard to debug and the learn curve is sharp.

Last edited by redguardtoo (2011-12-21 07:55:25)

lunar · 2011-12-21 17:18:44

@redguardtoo: Pointing out equally awkward languages doesn't really contradict my point.

Concerning its language, I'd put CMake among with make, autotools, and the likes, since it shares the same weakness, e.g. the lack of real data types, weird and counter-intuitive variable scoping and expansion or clumsy macros and functions. From this point of view, even Ant is superior, because it has sane variable expansion, and can be extended in Java, whereas CMake can only be extended in CMake. The major advantage of CMake isn't the language itself, but instead that there is only a single awkward language, not two or three (like in Autotools), among other things like extraordinary cross-plattform support, many built-in modules, and a good build configuration system.

I never understood, why the CMake developers still invented their own language instead of building upon Python, Lua or Ruby, despite the experiences from Autotools. There is probably kind of a secret agreement among build system developers to never use a sane configuration language.

Franek · 2011-12-21 22:00:55

lunar wrote:

There is probably kind of a secret agreement among build system developers to never use a sane configuration language. ;)

Hm... premake? It uses Lua syntax.

tavianator · 2011-12-21 23:39:36

If you're looking for sane treatment of types and scope, scons seems like a good bet, considering your build scripts are just Python scripts. I've never used it seriously though.

redguardtoo · 2011-12-22 04:25:28

lunar wrote:

@redguardtoo: Pointing out equally awkward languages doesn't really contradict my point.
Concerning its language, I'd put CMake among with make, autotools, and the likes, since it shares the same weakness, e.g. the lack of real data types, weird and counter-intuitive variable scoping and expansion or clumsy macros and functions. From this point of view, even Ant is superior, because it has sane variable expansion, and can be extended in Java, whereas CMake can only be extended in CMake. The major advantage of CMake isn't the language itself, but instead that there is only a single awkward language, not two or three (like in Autotools), among other things like extraordinary cross-plattform support, many built-in modules, and a good build configuration system.
I never understood, why the CMake developers still invented their own language instead of building upon Python, Lua or Ruby, despite the experiences from Autotools. There is probably kind of a secret agreement among build system developers to never use a sane configuration language.

Actually, I do not enjoy the "syntax beauty" of cmake at all (for example,cmake force me to write "endif()" instead just "end"). But I read/write less code in cmake, that's the most important benefit.

ruby/python dependency is not proper for c/c++ projects (especially some embedded system).
Lua would be good but cmake developers ALREADY made the decision, as cmake guy Bill Hoffman said,

> > On Dec 14, 2007 2:38 PM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> > > It really boils down to this: There is no way we can ever stop
> > > supporting the current cmake language. It would be a huge break in
> > > backwards compatibility.

And here is Bill Hoffman's conclusion,

OK, so here are my thoughts on using CMake as a full scripting language. ...
I think it is feature/mission creep. When I started CMake, I was trying
to make a tool that would make building software with native tools easy
for non build system types of developers (mostly researchers). Usually
on a team of developers there is one person that knows how to build
software, and that person maintains complicated makefiles/autotools
stuff, and maybe a windows developer on the team maintains some visual
studio project files. CMake is meant to make the build system
accessible to all the programmers on the team. The input should and can
be simple for many projects. It should be easy to link in external
libraries and to create libraries for others to use. I think CMake has
meet those goals fairly well.
However, I never intended for the language to be used as a general
purpose programming tool. There are much better languages out there for
that type of thing. When compared to perl/python for text manipulation
processing CMake is a poor choice. If on the other hand, you want to
build a c/C++ project CMake is a good choice. I don't think it is a
worth while effort to try and compete with perl/python. Use the right
tool for the right thing. Scope creep is a common pitfall for software
projects. Here are some wiki entries about the issue:
http://en.wikipedia.org/wiki/Creeping_featurism
http://en.wikipedia.org/wiki/Scope_creep
Scope creep is a more accurate term for what is going on with trying to
make the CMake language a competitor to perl/python.
As to why I regret starting this thread, I think it is a waste of my
time. Most likely 3 or 4 bugs from the CMake bug tracker were not closed
because I have been reading/writing emails on this thread. As someone
pointed out there are plenty of bugs in the tracker to fix!
From wiki featurism:
> software which over-emphasizes new features to the detriment
> of other design goals, such as simplicity, compactness,
> stability, or bug reduction.
Adding a whole new language would not help the build process at all, and
would take away from all of the above. It would fork the project if we
did not support the CMake language forever. It would be classic CMake,
and lua CMake or something like that. Some projects would move over and
others would keep using the old stuff. Less of the bugs and build
features would get implemented. There are plenty of important build
features that need to be added to CMake that have nothing to do with
language. Those would get put on the back burner. And, it would all be
done for what? So, the language was more elegant? There are some vocal
complainers about the language, but I suspect there is a silent majority
that really don't care, and are just happy to have the software build
correctly the first time they build it. (I could have fixed at least
one but instead of writing this email.... ).
-Bill

Ant is my current nightmare because the XML based syntax, which is too hard to maintain for big project.

I didn't consider using scons in my project because this article, Why the KDE project switched to CMake -- and how (continued). KDE tried scons and aborted.
IMO, cmake is best for C/C++ projects,
- big names and success story (KDE)
- normal syntax (NO XML)
- cmake is all (for example, package system is included), no 3rd party dependency
- NOT extendable with any other REAL programming language (Why find a java/ruby developer for a c/c++ project simply because the build system is extendable with java/ruby)

Last edited by redguardtoo (2011-12-22 07:50:22)

lunar · 2011-12-22 09:07:53

@Franek: But no one uses premake And as far as I see, it doesn't provide built-in support for libraries, or even tools like pkg-config.

@redguardtoo: I fail to understand your point about dependencies and embedded systems. Isn't CMake a dependency, too?! And why do embedded systems matter?! One doesn't build on embedded systems, but for these, on a separate development system, where you can install whatever compiler, interpreter and library you need, including Python and Ruby. So why are CMake and Lua acceptable dependencies, while Python and Ruby are not?! Don't forget that we're talking about the build system, not about the actual project itself.

Concerning your last point, CMake is a programming language too, or at least it looks like one as soon as your build system includes some real programming beyond simple configuration, meaning as soon as you're writing your own packages or modules for CMake. Thus one could also ask: Why find a CMake developer for a C/C++ project simply because the build system is extendable with CMake? Of course this question is nonsense, because someone just has to maintain the build system, and you wouldn't want to configure building in C++ or even C. But it is nonsense no matter what other language you substitute for CMake. Whatever language the build system uses, the build system maintainer may have to learn this language first, be that Python, Ruby, some XML dialect or CMake. After all, CMake isn't a native skill to each and every C++ developer, and also not particularly easy to learn with all its pitfalls (e.g. "if(${foo})").

Btw, don't compare Ant with CMake. Ant is just a build tool like Make, and something that a build system like CMake would be based upon. Take a look at maven for a real build system for Java, and to see, how build systems really should look like.

Last edited by lunar (2011-12-22 21:29:43)

DrMonkey · 2011-12-23 02:35:27

Hi,
I use waf for minimal to large C/C++ multi-plateform projects (scientific computing) and I'm extremely happy with it.
- Build files are Python script, like Scons
- Build things as fast as Make does
- Does a good job at auto-detecting things like compilers
- No need to install anything aside Python
- Does not requires you to have one file per directory, does not pollute directories with intermediary files
- Very good yet concise documentation
- Gentle learning curve, things are quite logical and intuitive is you're familiar with Python
- Complex stuffs are not too hard to do ie. build program A that generates source code for program B

http://code.google.com/p/waf/

Last edited by DrMonkey (2011-12-23 02:38:29)

redguardtoo · 2011-12-24 02:49:32

@lunar:
Say cmake's script lanauage is python, then in a big commericial c++ project,
1. we need waste our resource to install python.
2. some 'smart' guy will play with syntax candy (or even worse, some 3rd party libs) and make our build script has some platform compatibility problem.
For example, python 2.6 has different syntax support on exception handling.
3. Other teams want to reuse our component in their current project, any incompatibility will become maintainance nightmare for me.

Last edited by redguardtoo (2011-12-24 02:55:27)

redguardtoo · 2011-12-24 02:53:05

The only shortcoming of cmake is the makefile produced by cmake will call cmake's executable.
bakefile produce pure makefile instead. bakefile is used by wxwidgets.

lunar · 2011-12-24 10:48:05

@redguardtoo: Say, your big commercial C++ project uses CMake right now, then:
1. We need to waste resources to install CMake.
2. Some "smart" guy will fail to keep to "cmake_minimum_required()" [1], use some third party module [2], or call some third party utility [3], and make your build script have some platform or version incompatibility problem.
3. Copy your third point literally here.

See the point?

[1] CMake doesn't enforce the version declared with "cmake_minimum_required()". You can easily use CMake 2.8 features in a project declared "cmake_minimum_required(VERSION 2.6)".
[2] Every KDE project does so.
[3] Like [2]

Themaister · 2011-12-27 19:20:07

Make is fine, what is always annoying to get somewhat right is the configuration parts.

*shameless plug*
I use something of my own design, Quickbuild, in some of my projects that needs configurability, checking for libraries, etc.
It runs in POSIX shell, and is run exclusively there, so the learning curve is near nil. No other dependencies other than the shell either.
Its purpose in life is to create config.h and config.mk to be used by C/C++ source and the Makefile.
The shell source is designed to be embedded inside the program, so no external dependencies either.
To the user it acts kinda like autotools, as they do ./configure --prefix=/foobar --enable-somestuff && make && make install as they always did.

One example of it here: https://github.com/Themaister/SSNES/tree/master/qb

jlindgren · 2011-12-29 03:17:47

We use https://webkeks.org/hg/buildsys/ for Audacious. It's basically a Makefile template; you write a tiny Makefile with a couple of lines like "SRCS=all.c your.c code.c" and "PROG=myprog" and then "include" buildsys.mk. I find that it makes maintaining a large project (250,000 lines, dozens of subdirectories) fairly easy, but the learning curve may be steep; there's basically no documentation.

Franek · 2012-01-07 17:01:06

lunar wrote:

@Franek: But no one uses premake And as far as I see, it doesn't provide built-in support for libraries, or even tools like pkg-config.

To be fair, the Premake forum seems to be quite active, and libraries are supported. As for the pkg-config part, you appear to be right; this is easy to work around, though.

zester · 2012-01-07 20:04:41

Personally I use premake and love it.

As far as no one using it. Ill have disagree with you on that
I find my self running into more and more projects that use
premake everyday. Popularity wise amongs the different
build systems.

1. Make
2. Cmake
3. Premake & QMake

And as far as Ant the only projects that I know of that use it
are from Apache.

annulen · 2012-01-26 17:00:41

>Premake & QMake

Now you can also use Premake for building Qt projects instead of QMake. Qt support add-on tries to mimic qmake's behavior as close as possible, so in general it's much easier to migrate to Premake than to CMake.

cra · 2012-03-08 10:21:02

I prefer cmake but if you familiar with Python you can look on Scons which I see as the only possible alternative to CMake

CMake modules syntax is easy to read and I use it for my c/c++ coding and latex scripting. It also comes up with nice features as out-of-source build which is handy for example if you like to use /dev/shm as /tmp

Arch Linux

#1 2011-12-19 15:20:55

Build systems, anyone?

#2 2011-12-19 16:26:29

Re: Build systems, anyone?

#3 2011-12-19 19:30:24

Re: Build systems, anyone?

#4 2011-12-20 11:24:24

Re: Build systems, anyone?

#5 2011-12-20 13:53:42

Re: Build systems, anyone?

#6 2011-12-21 07:48:33

Re: Build systems, anyone?

#7 2011-12-21 07:54:39

Re: Build systems, anyone?

#8 2011-12-21 17:18:44

Re: Build systems, anyone?

#9 2011-12-21 22:00:55

Re: Build systems, anyone?

#10 2011-12-21 23:39:36

Re: Build systems, anyone?

#11 2011-12-22 04:25:28

Re: Build systems, anyone?

#12 2011-12-22 09:07:53

Re: Build systems, anyone?

#13 2011-12-23 02:35:27

Re: Build systems, anyone?

#14 2011-12-24 02:49:32

Re: Build systems, anyone?

#15 2011-12-24 02:53:05

Re: Build systems, anyone?

#16 2011-12-24 10:48:05

Re: Build systems, anyone?

#17 2011-12-27 19:20:07

Re: Build systems, anyone?

#18 2011-12-29 03:17:47

Re: Build systems, anyone?

#19 2012-01-07 17:01:06

Re: Build systems, anyone?

#20 2012-01-07 20:04:41

Re: Build systems, anyone?

#21 2012-01-26 17:00:41

Re: Build systems, anyone?

#22 2012-03-08 10:21:02

Re: Build systems, anyone?

Board footer