--- Peter Donald <[EMAIL PROTECTED]> wrote: > However ask Diane - there are a lot of things that make it difficult to > setup complex build environments.
Okay, so no one's actually followed up yet on Peter's directive and asked me, but I figured I should go ahead and take the opportunity to describe it nonetheless (maybe someone can even come up with some brilliant way of doing things that I've not thought of)... 1. Some statistics: My build output tree ends up with 7,067 files -- 4,156 of which are classfiles. Since I'm new to the world of Java applications, I'm not sure what qualifies as "large". Certainly, in the C world (which I come from), that wouldn't be considered all that big -- but it does seem like most people (here anyway) are dealing with smaller projects. I currently have 1 top-level build-file (for targets that deal with the whole tree), and 64 "subproject" build-files. 2. Compilers: Initially, the conversion to Ant also meant the conversion to jikes. However, jikes has a couple of odd bugs (the 12.0-to-NaN being the oddest :) that preclude my being able to use it just yet -- so, back to VCafe25's sj compiler instead. Which means Ant needs to be able to do both for now, at the flick of a (command-line) switch. Neither compiler uses the run-time classes for the JDK I run ant with, which is jdk1.3 -- I need to run in at least >jdk1.2 because I run from an MKS korn-shell window on NT, and if I use any earlier JDK, anytime a <javac> task is run, I get a goofy DOS window popping up and almost immediately popping right back out, since the task runs so quickly (it's rather like Whack-a-Mole :), and I figured I might as well go with jdk1.3, since it has a faster jar command, etc. So I have to a) have a modified Javac.java that turns off adding run-time classes, and b) have a command-line property-define that specifies the "env" to use (ie., which classes.zip to include in the compile-time classpath -- for sj it's theirs; for jikes, it needs to be jdk118's) so ant will read in the right property file that sets the compile-time classpath appropriate for the specified compiler (along with 20 other assorted jars/zips and the weblogic/classes dir). 3. Build-order issues: Not only do I have to use a specific classes.zip in conjunction with the (user- or default-) specified compiler, I also have numerous source-files that require jdk122 (and even some jdk13) classes. So I can't just hand off all the source-files at once, I have to feed them in selectively. And because Java compilers have that cute trick they do of going off and side-compiling whatever they need whenever they need it, I have to accommodate that by making sure that nothing that's currently compiling against the 118 classes ends up pulling in something that requires 122 or 13 classes -- and vice versa. And to add to the fun, sj and jikes don't end up doing the same side-compiles (hmmph). So I have to try and not only accommodate the build-order issues wrt what classes are currently available, but also wrt what build-order will work for both sj and jikes. In all, I have 103 <javac> tasks (out of a total of 213 tasks) that get run for a full scratch build. 4. I also have to allow for what "state" the build is being run in -- one that compiles-in the debugging code, and one that doesn't. Which is why I have a modified Target.java that allows for test-for-value in an if/unless -- I need the value of the "sane" property to literally be either "true" or "false", not merely set or not set. (The value is used for several things, including as a filter-token for a gen'd .java file.) 5. Extraneous source-files: I have .java files in the source-tree that should not be included in the build at all. Getting rid of them is not an option (I got rid of as many as I could, but that's pretty much that). 6. All the rest: The other things I need to do are actually pretty straightforward, and don't pose any particular complication (things like gen'ing parsers, splitting message-files, copying support files, etc.) But of course, this is all just dealing with the "development build" -- there's also all the things that need to happen for a "nightly build & test", which I've only partially implemented so far, and which involves <script>'ing and a lot of <exec>'ing and <jar>'ing -- and then there's the "installer build" stuff (which I've managed to plop onto someone else's plate :) Originally, I did start out having only a top-level build-file -- but there just wasn't any way to keep it. I want developers to still be able to be in a subdir and just say 'ant' and not have to specify a particular target. I toyed with the idea of having the wrapper-script figure out the pwd and deducing which target it should run based on that, but that precluded the possibility of their being able to just run the "compile" target (or any other specific one) for the subdir they were in. And I was also still left with the problem of having this humongous build-file at the top of the tree. I want people to be able to maintain the targets that apply to their "area" of the tree, and the size and complexity of the single top-level build-file was more than I wanted them to have to deal with (along with the possibility of editing collisions, once Ant actually becomes the real build tool -- right now, it's only "on trial"). Even the "package-level" build-files I have are more difficult to deal with than I would prefer -- I would much rather they not have to deal with the "bones". But there's really no way to just use includes/excludes files for the compiles because of the different classpath needs for certain files and the build-order issues. So I've done what I can to keep the "package-level" build-files are simple as I can, and make them all as consistent as possible -- but that's about the best I can do for now. But the Ant build-files still aren't anywhere near as straightforward to deal with as the Jam build-files were, and I'd really like to have that change at some point (which is why I miss being able to define "rules", and being able to associate certain things "on" particular tasks [a la Jam]). I'm also of the opinion by now that the logging for Ant is far from ideal. Pete was nice enough to offer up an alternative earlier today, but even that doesn't really behave the way I'd like (apparently <echo> tasks aren't regarded as "build events"). I would also like to see dependent targets indented a couple of spaces, so it's clearer which is what. And to top everything off, I haven't had any time to sit down and actually learn Java, so the most I can do at this point is hack at things as best I can. I -can- get things to work the way I want them to, but it takes me a whole lot longer than it should. Well, that's my Real World story... I hope it sheds some light on how at least this end-user is using Ant. And speaking of light -- if any lightbulbs go off for anyone about how to approach some of my stickier situations in a better way, I'm all ears... Diane ===== ([EMAIL PROTECTED]) __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
