What is the right way to build C++ project? Make/IDE/Ant...? [closed]

Question

There is number of ways how to manage a build of a project. I know about these possibilities:

• Make
• IDE
• Ant
• Maven

Can we say that some of them (or even some other that I don't know?) is in general superior to the others and should be definitely preferred on a new project?

At this moment I use on my project a build managed by Eclipse IDE and I consider migrating to makefiles. Somehow I feel that it will be more manageable, but on the other hand, it is actually the goal of IDEs to make things more manageable. So am I just going to do harmful work trying to return to something old fashioned? I have a great experience with Maven from a Java project, but is it a good idea to force it with C++ (although I know that it is possible...)?

Answer 1

Most C++ build systems that still exist, do such for a reason. Which is to say, they are better than the alternatives in some way. (Except the build systems that have you writing XML, sorry ANT)

But in general, we see some patterns of usage emerge.

You in general only see IDE projects used for MSVC and XCode. This is due to the better integration, with the IDE, yes. But more importantaly, the Platform. VC++ is particularly well supported by the IDE projects, and generally has very poor support otherwise, except for things which end up generating the projects. I've never seen a c++ project that builds with eclipse, but that may be related to not ever seeing c++ programmers who code in Eclipse.

On unix platforms, you generally see some variant of Makefiles being used. It seems that this is related to wanting a good least common demonitor to build projects from, since most code is distributed in source form.

Projects like CMake (project generators) are often used when platform independience is a top priority, you gain some overhead due to generate->build steps going on, But gain being able to build the project on multiple platforms from a single buildbase.

I've really only seen ANT used to performing continious builds, and even then, generally it calls a seperate build step, I'm not sure why this is.

Then I've also seen a lot of usage for things like Jam(make replacements) in proprietary projects that target *nix/Mac or other less common platforms. Particularly in game development, I think this is generally from teams that like Make in theory (The concept of treating your buildsource like you treat your code, no WYSIWYG and the like) but understand that Make is broken. Yet have the luxury of not having to do source distributions.

This is just a bunch of patterns I've observed, and trying to rationalize it, very little of this is based on objective-truths.

Answer 2

When going for platform independency, I have achieved good results using Cmake. Its configuration is based on textfiles and it produces "real" build scripts like Makefiles or the appropriate projects for IDEs. If you have no problem with introducing some sort of pre-build step, I would go for it.

In cases where I can stay platform dependent, I just go with whatever I prefer. Typically Visual Studio Projects / Solutions on Windows and Makefiles on Linux.

Answer 3

I'm assuming you are using the Eclipse CDT. The build process is actually Makefile-based already. However, I think the CDT generates the Makefile at compile time. Perhaps somebody else could verify that for me. Regardless, in the CDT you can create a "Makefile" project. That type of project allows you to use pre-existing source and its Makefile instead of starting from scratch.

Another thing to consider is do you have a requirement to support headless builds (e.g. as part of a CI or other automated build process)? If so, then you will want to definitely choose a build technology that supports that (like Make).

For info on how CDT uses Makefiles: Eclipse documentation