Hi, On Sat, Oct 30, 2010 at 12:00:03PM -0400, cmake-requ...@cmake.org wrote: > Message: 1 > Date: Sat, 30 Oct 2010 13:54:23 +0200 > From: Benjamin King <benjamink...@web.de> > Subject: [CMake] Converting a large C++-Project to CMake > To: cmake@cmake.org > Message-ID: <4ccc076f.6040...@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 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
