[CMake] continuous builds best practices?

Philip Lowman philip at yhbt.com
Fri Apr 3 02:03:56 EDT 2009


On Thu, Apr 2, 2009 at 5:06 PM, Alexander Neundorf
<a.neundorf-work at gmx.net>wrote:

> On Wednesday 01 April 2009, Philip Lowman wrote:
> > Is there a best practices for kicking off Continuous builds using ctest?
> > What do most people do for this?
> >
> > I know about svn hooks but I don't want multiple builds spawned for each
> > commit, just the latest commit when the machines are idle.  Also, I have
> > multiple build machines on various operating systems.
>
> I think it's usually just "time triggered", e.g. every 15 minutes or so.


Yeah I tried something like that and realized I would have to give up
cleaning the build directory because it seems to recompile everytime, even
if the svn revision number hasn't changed (bug?).  I don't use a config.h
file so not rebuilding from scratch on every commit could potentially break
the build on MSVC.

I think I have a better idea which would be to turn ctest into a daemon that
connects to a build server which sends out a per-branch pulse when a commit
occurs.  Connected clients that are idle and interested in the pulse (by
having already examined CVSROOT or svn info) could immediately start their
builds.  Clients that are busy would queue their update & start their builds
when the existing builds finish.

ctest --daemon http://my.cdash.server.org/check.php \
   -S foo-continuous-msvc80.cmake \
   -S foo-continuous-msvc90.cmake

In this way the continuous builds could be started nearly instantaneously
after a commit.  Long polling could be used on the CDash server to make this
work through proxy servers.  One could also envision CDash keeping tabs on
connected sites and being able to inform the site administrator if one goes
down in the middle of the day.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090403/139cff64/attachment-0001.htm>


More information about the CMake mailing list