Having an agreement between developers and the build team will keep everyone's expectations in check.

Below should be the minimum of any document.

You need at least these items:
What output is expected?

What setup is needed?
Configuration:
Pre-requisites:

What input will be used?
VCS: Branch? Modules?

http://www.javaranch.com/journal/200603/AntPart1.html is a good article about some advanced techniques.

Visualizing Data: Self-Documenting Ant files is a good page to start this brand new page with.

I like the idea of having a help task like this:

Figure 7. Help Target Output: After you instrument the code with a "help" target, launching Ant with no arguments gives you the same result as using the "-projecthelp" argument.

If made the default task, it will really run ant -p -f so kind of self-documenting.

" Executing Adobe Begin on Windows XP on a Non-Development Machine

When an app is built using a version of MSVC, that version of Microsoft's Runtimes Libraries must be 'findable' by the OS in order to launch the application. Part of Microsoft's solution to this problem includes the embedding of an application manifest file into the application. On development machines, these files are automatically installed in C:\WINDOWS\system32\. The manifest file describes the binary's dependencies to external DLLs, and the OS reads the file and hunts down the dependencies to load them. In a clean-install XP system, the Runtime Libraries for MSVC 7.0, 7.1, and 8 do not exist, which will lead ultimately to the failure to launch applications built with these compilers on non-development machines.

Update: http://www.javaforge.com/proj/doc.do?doc_id=53942 is the latest release of Luntbuild. Just download the installer jar: http://www.javaforge.com/displayDocument/luntbuild-1.6.0-installer.jar?d... and then run it via:
java -jar java -jar /luntbuild-1.6.0-installer.jar
If you develop software, you should use Luntbuild. It has more features then most other open source building tools.

http://luntbuild.javaforge.com/ is the main page. It is not the most reliable site, being a sourceforge.net project you can get it here as well: http://sourceforge.net/projects/luntbuild/ .

There is no silver bullet to solving a bad build process. But Luntbuild allows multiple users each with a separate viewing options. So, you can communicate with your customers and bosses about the build and how it is improving.

Changing how it works is done via a web interface to a database back end. So, you aren't changing fragile XML files, you are updating a database.

Please see the bottom of this page for links to several resources. (click read more!)
Building software is a list of steps needed to take source code, images, other things called artifacts into something useful.

Critical Best Practices:
1) Software reproducibility
2) Decoupling your process from your hardware
3) Build early and often
4) Combine technology with the human process

Here is a text of a podcast from IBM and Sundeep Goel. He makes several good points.

When you actually build an application you will need to maintain it. This means even though you working on 2007.5 version of your code, somebody with 2005.2 might need you to rebuild the application.

Software needs to be built. The problem is as the complexity increases, the build suffers. If you use make, you should look into "Jam". It is available here: http://freetype.sourceforge.net/jam/index.html and the original is still available on the perforce website, but you want to use the one from Source Forge (SF) anyway.

Here is a web page on how build times have been drastically reduced by switching from make to jam: http://public.perforce.com/guest/neal_firth/JamUseI.html