tags:

views:

230

answers:

6

I'm using Mercurial for development of quite a large C++ project which takes about 30 minutes to get built from the scratch(while incremental builds are very quick).

I'm usually trying to implement each new feature in the new branch(using "hg clone") and I may have several new features developed during the day and it's quickly getting very boring to wait for the new feature branch to get built.

Are there any recipes to somehow re-use object files from other already built branches?

P.S. in git there are named branches within the same repository which make re-usage of the existing object files possible for the build system, however I prefer the simpler Mercurial separate branches model...

+3  A: 

A simple way to speed up your builds could be to use a local "build directory" on your disk. This way you can checkout into this directory and start the build. The first time it will take the full time, but after that it will (hopefully) only rebuild the files where the source code changed.

schnaader
+1  A: 

Mercurial also has local named branches, see the hg branch command.

If you insist on using hg clone to do branchy development, I guess you could try creating a folder link (shortcut under windows) in your repo to a shared obj folder. This will work with hg clone, but I'm not sure your build tool will pick it up.

Otherwise, you probably keep all your repos in one folder - just put your obj folder there (it shouldn't be under source control anyways, imo). Use relative paths to refer to it.

Kurt Schelfthout
Thanks for the tip. I think sharing a separate directory for object files should really work.
pachanga
A: 

A word of warning: many .o symbol tables (or equivalent) contain the full path name of the source file. If that other file changes (or if the path is not visible from the new directory) you may encounter weirdness when debugging.

Peter Rowell
+4  A: 

I suggest using ccache as a way to speed up compilation of (mostly) the same code tree. The way it works is as following:

  • You define a place to be used as the cache (and the maximum cache size) by using the CCACHE_DIR environment variable
  • Your compiler should be set to ccache ${CC} or ccache ${CXX}

ccache takes the output of ${CC} -E and the compilation flags and uses that as a base for its hash. As long as the compiler flags, source file and the headers are all unchanged, the object file will be taken from cache, saving valuable compilation time.

Note that this method speeds up compilation of any source file that eventually produces the same hash. If you share source files across projects, ccache will handle them as well.

If you already use distcc and wish to use it with ccache, set the CCACHE_PREFIX environment variable to distcc.

Using ccache sped up our source tree compilation around tenfold.

ASk
+2  A: 
alu
+2  A: 

My Localbranch extension was designed partly around this use case. It uses a single working directory, but I think it's simpler than git. It's essentially a mechanism for maintaining multiple repository clones under one working directory, where only one is active at a given time.

brendan
Thanks, I'm gonna try it!
pachanga
BTW, I'm a bit lost - there is also bookmarks extension which seems to be doing pretty much the same job... Could you please explain the difference?
pachanga
The basic difference is that localbranch creates completely separate repository clones underneath the working directory, whereas bookmarks are pointers to different revisions in a single shared repository. Bookmarks are more like what git does, but because the hg repository format doesn't really support garbage collection the way git's does, you can't easily remove a "bookmark" branch from your repo the way you could delete a clone, and for instance hg log will look odd because the revisions of the different bookmarks will be intermingled.
brendan
Thanks a lot for clarification
pachanga