Build Tool Requirements
From Apache OpenOffice Wiki
This page describes some requirements for tools to be integrated in the build process. While it is more realistic to focus on tools written inside the OpenOffice.org community, the same requirements should be a guide when choosing external tools.
must:
- in case of problems the tool must state an ERROR instead of silently exiting. Furthermore a returncode != 0 is mandatory in such cases (and returncode == 0 in case of success) and meaningfull error messages may be helpfull.
- in case of abnormal termination or concurent writes it must be guarranteed that there is either correct or no output. A common way to do this is to write to temporary files and do an atomic rename when finished. These temporary files of cause should be cleaned up in case of an error.
- output files must get read/write permission for user and group (presumed users umask is correct). This may need special attention in case files are created by system's temp file mechanism and renamed afterwards - temporary files normally are accessible for the pwner only.
- do not write files into the source tree. Even temporary files have to be generated into the (platform or common) output tree.
- use unique file names when writing into temp directory. Otherwise you would risk clashes in parallel builds.
- in and out files/directories can be specified on the command line. A usefull default may exist but must be overrideable.
- common practices of file i/o of course apply also to build tools (avoid filesystem operations, block r/w instead of single chars, etc.)
- avoid platform dependencies. Tools should run on every platform and with the same syntax (command line).
- interactive GUI/CUI tools are of course inacceptable...
should:
- tools shouldn't create an unpredictable bunch of output files. Allthough this might be a performance issue, it makes handling of these tools in the build process that complicated that it might be no gain overall. This is especially true if safeguarding mechanisms are involved.
- avoid writing error output files, as dbgsv.log or *.err, into the source tree. Those stuff will accumulate with time.
- avoid creating new prerequisites. (e.g. there is no need to introduce the nth XML parser for java...)
