[EMAIL PROTECTED] wrote: > > 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.
Totally agreed. > 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. Agreed also on the analysis. > 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. I don't think so: Ant sintax is really simple and straightforward. Tomcat build.xml is complex because tomcat is complex. Most java applications require a couple of lines of build.xml like in my previous message I outlined. > 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'm coding this right now to get rid of makefiles in Cocoon. > I would be curious to know what the > Jakarta folks' experience > with ANT has been, regarding the approachability of the configuration files. They had no problem at all. This is the power of Ant: is java specific. If you change class names, package names, and blah blah, you don't have to change anything in your build script. Ant will take care of that. Also, Ant will not recompile what you have already compiled. It may use jikes instead of javac and generate your docs using stylebook or your Java code using XML/XSL (like FOP is doing right now), simply depending on the task element you want. And if something is missing, plug in your own task and you're done. I think such a project is really cool and it should deserve it's own project, maybe here in between the XML stuff. > 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. I don't like jmk either. > The ideal solution would be a Java implementation of Makefile syntax, but > I'm not aware of > such a tool. Why? because people know make syntax more? Granted, but how much does it take to learn a DTD from examples? How long did it take to write your first HTML page looking at someone else's one? C'mon, we are the Apache XML project after all :) -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche
