3

I've just moved a large project out of a legacy version control system, and into Mercurial. I'm now faced with the task (opportunity!) of overhauling my old build system to work with this new source control system.

Are there any good build systems that:

  • Can build projects in a variety of languages and compilers
  • Integrate well with Mercurial (For example, knowing to pull certain revisions or tagged versions of sub repositories for dependency management (as opposed to continuous integration.))
  • Extendable (we have several auditing steps that we need to perform before and after our build)
  • Are easy to use

that are already out there? As much fun as building and maintaining yet another build system might be, I'd rather reuse a mature, stable product and get back to developing my own code. :) If no tool exists with Mercurial in mind, what else might meet the requirements? What else might be out there that I'm forgetting?

Robert P
  • 15,707
  • 10
  • 68
  • 112

1 Answers1

2

Usually your build tool/system and your continuous integration system are separate, and the later is the one that knows about your DVCS system. In my setup the build tool is sbt (formerly ant) and the CI system is Jenkins (which I highly recommend).

The CI system speaks Mercurial, but it doesn't have to speak much of it. Mercurial lets you create URLs that track a specific named branch or tag, and so long as your CI system can clone/pull you're set. Once the CI system has updated to the version you want to build then it triggers you build system, which needs only look at the working directory.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Thanks for the comment. You're exactly right: I'm not talking about a CI tool at all when I mean "pull specific revisions or tagged versions", but rather, dependency management (per another recent SO question.) I guess it was too much to hope that there might be one that does everything I need automatically, eh? :) – Robert P May 24 '11 at 16:02
  • Yeah, though working in concert you can get a lot done. Your CI system can make tagged builds available at durable URLs which your builds system's dependency resolution system (like ivy2) can use to pull in the right builds of other components. – Ry4an Brase May 25 '11 at 14:36
  • Aah, what I meant by being able to pull tagged versions was not so much as part of testing, but as part of making the build. For example, I might have some Lib-Foo-1.2.3 that my project needs, but I don't want to include it in the source tree - I want to pull it from its OWN source tree. SCons, for example, has the ability to pull CVS sources as an action. It looks like I can make a custom action to pull those dependencies, if I wanted, but I didn't know if there was anything else out there that knew about Mercurial natively. – Robert P May 25 '11 at 16:42
  • Even during build time it's nice to build against CI-generated snapshots -- saves time and there's one for every commit if your CI system is running all the time. Alternately you can use subrepos to include other Mercurial (and git and svn) repos in your repo. Or you can have your build `clone -r tagname URL_OF_REPO` to pull down sources at any point you'd like. – Ry4an Brase May 26 '11 at 02:42
  • Good points. I come from a world where CI is not the standard, but nightly builds are - primarily due to limitations in our old version control system. Subrepos is my current strategy for keeping track of external resources. As I discussed [here](http://stackoverflow.com/questions/6020936/whats-a-good-way-to-organize-projects-with-shared-dependencies-in-mercurial), I have a pretty complex dependency tree, and I was hoping my build tool could help me manage some of that...without having to write it myself. Looks like I might have too. :) – Robert P May 26 '11 at 18:00