Here's what I've heard so far in terms of requirements for the build: a) We should stick with pervasive build tools, so people can edit/debug more easily, and so that we can rely on the tools being present in the target OS. b) If we use a non-make tool it better be in the download. c) We shouldn't maintain two parallel build systems, one for UNIX and one for Windows.
Here are my specific beefs with the current system: 1) It uses GNU make. This means that someone has to install GNU make on some Unices. On Windows, it means someone has to install either Cygwin (free but multimegabyte) MKS Toolkit (costs $$$), or have a make from something like VC++ (also costs $$$) I don't believe that we can rely on the target machine having the right make based tool. The current build system relies on Cygwin on Windows and some make on UNIX. Even this requires too much setup of environment variables for things like classpaths, and cygwin's MAKE_MODE, etc. In order to build the Java version of Xerces (which is what we're discussing here), you will have to have Java. If we had a Java based tool, we could eliminate all reliance on an extra build tool. AFAIK, there are only two choices: ANT and jmk (http://www.ccs.neu.edu/home/ramsdell/make/edu/neu/ccs/jmk/) The problem with ANT is that it is a non-pervasive tool. It uses a configuration file syntax the most people have never seen. People will complain about this, and it will make it harder for people to help out with build related stuff. Also, the current build does a few things that ANT doesn't have direct support for (except via Exec, which I'm not sure will do the job): running stylebook to generate the documentation, and running javadoc to build the API docs. It looks like it would be easy to extend ANT to do these two tasks correctly, if that turns out to be necessary. I would be curious to know what the Jakarta folks' experience with ANT has been, regarding the approachability of the configuration files. jmk is only a little better, because it uses a syntax that looks close to Makefiles, but isn't real Makefile syntax either. People (including me) will complain about this. Moreover, jmk is using the LGPL license, which might be a problem for us. The ideal solution would be a Java implementation of Makefile syntax, but I'm not aware of such a tool. 2) The rest of the problems with the current system are artifacts of quirky makefile design. If we decide to stay with Makefiles, the makefiles should be rewritten.
