[CMake] Converting a large C++-Project to CMake

[Andreas Mohr]

Hi,

On Sat, Oct 30, 2010 at 12:00:03PM -0400, cmake-request at cmake.org wrote:
> Message: 1
> Date: Sat, 30 Oct 2010 13:54:23 +0200
> From: Benjamin King <benjaminking at web.de>
> Subject: [CMake] Converting a large C++-Project to CMake
> To: cmake at cmake.org
> Message-ID: <4CCC076F.6040304 at web.de>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
> 
> Hello,
> 
> I'm working on a ~1.5Mio LOC C++ project and our buildsystem is a 

"me too" ;)

> hodgepodge of handcrafted Makefiles, shell scripts and qmake projects.
> I tried to convert a subset to CMake and it looks very promising so far.
> 
> One important part of our development workflow is this:
> 1) User 'nightly' builds versions of the project every night on several 
> development servers.
> 2) A developer is coming to the office in the morning, and 
> copies/hardlinks the nightly build to his home dir and probably patches 
> uncommited changes from yesterday into the newly copied build.
> 
> Our build is taking ages (almost a three hours on the fastest of our 
> servers) and it would be really painful if everybody needed to rebuild 
> everything for himself in the morning.

3 hours sounds quite excessively long.
On a bog-standard workstation (i.e., definitely _not_ "on the fastest of our
servers"), a (single-core) build here takes around 2 hours,
however a (partial) Linux CMake build is finished within 25(!) minutes
(make -j3) on a Core 2 Duo.
And this with some projects thrown in to the mix (of around 40 projects total)
that are _heavily_ templated i.e. rather more painful to build.

> According to the FAQ, CMake does not support copying build trees around. 

Yep, and I'd think that that's a pretty hard condition.
One really shouldn't try to bend things to work with specific build tree
data on multiple machines I'd think. That's just not the way that CMake
is supposed to be used.

I'd much rather suggest cutting down on rogue include file overhead
(check gcc -E to analyze amount to process on each file, and to see
which file gets included most often and/or in the most painful way).
This is a suitable way to decrease build pains in the case of
possibly more "chaotic" build trees (I once managed to get it down
from almost 3 hours to around 1:25 or so).

If however this doesn't cut it for you (i.e., tree size is a wee bit too large
for this to be feasible within office times),
then you should probably find a way to split sub projects into proper,
cleanly interfaced, external projects to be used for one large build project
as needed.
I.e., keep most parts as external dependencies (to be updated every
couple weeks/months when the "other" teams have a new achievement to
offer). And mainly work on the one CMake project (i.e., "your" project)
which then makes use of the other external projects.
Related CMake mechanisms here probably are ExternalProject_Add()
or Imported Targets.

Or, another way to achieve reduced build times might be things like
distcc, icecc, ccache.


On my side, I'm currently working on a flat CMake project space (and as said
above this is working sufficiently well),
however I might eventually change this to split off some suitable parts.

HTH, coming from someone with possibly rather similar conditions.

Andreas Mohr