http://zakalawe.ath.cx:8080/
is a *prototype* build server for FG (including OSG and SimGear), running on my home box - it will need a proper home if it moves beyond the prototype stage. For people who don't know, a build server talks to some slaves, and grabs/builds/tests/packages code. The current server is talking to one slave, which is an Ubuntu VM which is building Tim's 'next' branch on Gitorious. The objective of such systems is that there should be *zero* human steps to create a release - not just out of laziness, but for repeatability. I.e don't write a checklist or 'howto' of creating a release, write a shell script that does the steps. (Or several). And check those scripts into a source control system, too. 'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully this will even extend to a NSIS installer script, if Fred has one lying around. At which point we should have nightly installers available for Windows, and a happier Fred. (A VisualStudio build is also possible, but requires more interaction with someone else, who has an externally-addressable/tunnel-able box with VS installed). (any slave could be a VM, of course - they use CPU while building, but unlike other projects, our commit rate isn't that high - the slaves will be idle most of the time) (A Mac slave is also possible, but requires some more work, I will worry about it assuming people want to pursue this whole concept) Build jobs can run arbitrary shell scripts - they can tag things in CVS or Git, they can create tarballs, upload files to SFTP/FTP servers, the works. So, if Durk/Curt/Fred could codify, somewhere, the steps (in terms of 'things doable in a shell/.bat script') to create an FG pre-release and final-release, I am happy to do the work to get the process automated. At which point, doing a release means clicking a button on a webpage (on Hudson), and letting the slaves grind away for an hour or so. Magic! (Another thing the server can do, is email/IRC people when the build breaks on Linux / FreeBSD / Mac / Win due to a commit - obviously very handy for the devs. Yet another thing it can do is run test suites - unfortunately we don't have many such tests) (If anyone wants to get into providing nightly .debs or .rpms, that could also be done, but requires people who know those systems, and again can provide a suitable externally address slave to run the builds) James ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
