There were some problems or frustrations with the Creatures 3 build process and the tools used.
The Cygnus tools expect a Unix format file system. This has everything mounted under one root node /, rather than having drives c:, d:. All of the tools can happily access files using paths like "//c/program files/creatures 3/engine.exe", or network paths "//cyberbackup/clabs xtra/creatures 3/". The problem comes when calling external Windows programs with absolute paths as parameters. You then need to store the path name twice.
The first form is to pass to a Unix tool, and the second to pass to a Windows designed program.
Because of spaces in filenames, the syntax of cp and mv and other commands can be counterintuitive. This took up more time than expected. One solution is to learn this aspect of Bash syntax carefully. On some later projects we took the simpler solution of disallowing spaces in all filenames.
Like all good tools, it does take some time to write build scripts and maintain them. It's time well spent, but it needs to be budgeted.
There are lots of ways in which build scripts could be developed and improved in the future. I'm sure you'll invent lots of things as you integrate automation into your development process.
Here are some things we learnt from the Creatures 3 build scripts, and some general ideas to get you thinking:
Optimising network copying. It's easiest when writing the script not to worry about network traffic, but copying large assets about the place is very slow and clogs up your network. Perhaps ideally the build script should run on the project file and source control server. Alternatively, you can just pay attention when writing the script, and not needlessly copy large movies off the file server and then back onto it again.
What's the best way to segment the build into sections? The Creatures 3 scripts were broken into eight sections: engine, prepare, language, check, test, compile, commit, wolf. These sections can be tested and run independently. It would be useful to further break things down, as often there are independent subsections within each section. The more modular your script is, the more useful you will find running parts of it by themselves.
It would be useful if it could automatically restart in the middle. The Creatures 3 build process doesn't have any sense of where it is up to. Sometimes you can manually restart from halfway through, but you have to know what you are doing. It would be useful if the script tracked this. That way, when an error is found, the build can be resumed as quickly and reliably as possible, without repeating complete stages.
Web interface available to the whole team. It might be useful to have a user interface displaying progress of the current build, and allowing anyone with authority to start a new build. This would make the build process a tool owned by the whole team, rather than something one individual has to control. This empowers people more, and lets the team make a build whenever they need to. It might not be worth doing, as it is often helpful to have one person co-ordinating things.
Automatic error reporting. It would be possible to categorise errors, and report them automatically to the appropriate person, by email. This works well with the web interface, and has similar advantages and disadvantages.
Ability to run multiple builds at once, or easily sequence builds. This would make it easier to prepare different localised versions.
Modular and general purpose. It might be possible to make your build scripts more general purpose, so they can be used on several projects. It's not clear that this is practical, as every project will be quite different in its requirements. Scavenging code from previous projects is often easier. One thing to do would be to separate key bits into separate scripts - for example, "compiling with InstallShield", and "getting a project from source control and compiling it with msdev". This library of scripts could then be shared between projects.
Using an automated build process was an invaluable tool during the development of Creatures 3. We cut costs and increased quality. Partly because of this, Creatures 3 was completed both on budget and on time.
You can easily integrate a build system with your existing development environment. You will learn new skills, and enjoy life more. Let no developer repeat tedious tasks by hand on a computer ever again.
and Using the Tools
Since RedHat took over Cygnus, it has been quite hard to ferret a version of the Cygwin tools from their web site. Things look easier now, just go to http://sources.redhat.com/cygwin/ and follow the instructions.
Under Windows, the easiest way to install Perl is using ActiveState's distribution. Go to http://www.activestate.com/. This also installs a useful version of the Perl documentation which you can access from the Start menu.
The definitive sources of documentation are the somewhat dry online manuals. You can read some of them with the man command, or find them online.
There's a good Bash tutorial at http://www.beforever.com/bashtut.htm. It is for BeOS, but very little is platform specific. Make sure you also read the Cygwin User's Guide for the Windows specifics.
is a good looking Perl tutorial http://www.netcat.co.uk/rob/perl/win32perltut.html.
Perhaps a bit detailed for a build script, but useful if you need