The distributed build is not to make it run faster. It is so that the build process can build the c++ on a linux box, and the .net build on a windows box. Both can be tied together under a common build stamp. They can be interop tested (by calling scripts on both boxes). If the tests pass, the build artifacts, under the common stamp, can be promoted together as a succesfull build.
Its working out how to coordinate this process of building accross multiple boxes that I see as being the difficult part of automating a Qpid build. I had that in mind though, as I was writing the interop testing spec, trying to imagine how I would be able to get that sort of distributed testing to work. In anthill I set up agents, on a windows box and on a linux box. I then define a workflow that goes like this: create new build stamp. fork: build cpp on linux agent: build java on linux agent: build dotnet on windows agent. join: call broker start script on linux agent. fork: call startall test clients scripts on all agents. join: call coordinator start script on linux agent. call broker stop script on linux agent. publish the test results. (maybe some more steps here, like tck testing). if it all passed: gather consistently stamped build artifacts from all agents (the distributions). On 3/9/07, Alan Conway <[EMAIL PROTECTED]> wrote:
Rupert Smith wrote: > On 3/9/07, Alan Conway <[EMAIL PROTECTED]> wrote: >> distcc for make) not the continuous build system. "Native" make >> integration sounds nice but integration via ant is so straightforward >> that I can't imagine what additional value it provides. > > Well go ahead and write a distributed build system via ant then. Let > us know in a few months/years from now when it is ready. > Hah! Good one. I sortof assumed that there were tools already out there. Java compilers are so fast that I've never been on a project with enough source to need distributed builds. I wouldn't have thougt Qpid Java was that big/slow building but then my C++ background has acclimatized me to much longer build times. Anyway if we need distributed Java builds then that's a big plus for AntHill. > As I say, I got the maven build system hooked up through AH in 18 > minutes of configuration effort, cpp now hooked up in about 45 > minutes, not done the dotnet yet but as its just a single > build-dotnet20 script call, I'm getting better at it so I don't think > it'll take too long. That's pretty good - I spentlonger than that getting CruiseControl to do C++. What do the build/test results look like? Any highlighting/linking/other fanciness or just a big splurge of stdout? We can make the CppUnit tests barf XML, does AH support CppUnit directly? If not a bit of xslt will probably do the trick - that's what I did with CruiseControl to get nice formatted test result pages like JUnit. Cheers, Alan.
