Hey Freeland, All of this sounds great. The build scripts have been in severe need of tweaking for a while, and I'm glad that you've decided to tackle this tricky issue. I've got a couple of comments about the "ant test" behavior.
If it is the case that a subsequent "ant build" after running "ant build" is zero work provided that there are no code changes, then I am okay with having "ant test" depend on "ant build". However, if running "ant build" in a zero-work case takes a non-trivial amount of time, then we should re-consider having "ant test" depend on "ant build". I'd also recommend that running "ant test" rebuild the test classes themselves, and the build step for test code should be zero-work if "ant test" is run back-to-back with no test code changes in-between. A nice-to-have (i.e. less important than all of the other things you mentioned) would be the ability to specify specific tests via the command-line (maybe via a system property?). Rajeev On Wed, May 27, 2009 at 1:38 PM, Freeland Abbott <fabb...@google.com> wrote: > So, I'm looking at our ant files, and trying to unwind several problems... > but I figure I'll ask what other people have as pet peeves, to see if there > are other games I should play, too. > > Here's what's on my mind right now: > > - If you run "ant clean build; ant build", the second build should be > zero work. It's not, and in particular it painfully builds samples twice. > It shouldn't. > - Right now, tests require a staging directory, which implies requiring > a full distro kit including samples. That's unnecessary; tests should > require build, but not much more. > - Related to that, too much depends on the semi-recursive -do, which > is actually a no-op that depends on dist, which pulls too much in for > simple > cases. > - Largely orthogonal, we have checked in files with $ in their names, > which are supposed to also be usable wtih _ instead. I've got a system > which is badly allergic to the $'s, which is why this causes me pain, but > generally it seems this "should" be addressed with alternate classpath > roots > anyway, so we can test both the two cases easily. > > Does anyone have other pain points to add? > > > What I was thinking of doing is: > > - Shoot the top-level -do target, in favor of having subtargets > directly invoke what they need from subprojects, via <antcall>, and setting > "target" as is done today... so e.g. target "test" can depend target > "build" > or "buildonly" and then <antcall> the "test" targets of dev, user, etc. > explicitly. Since -do would no longer exist, it wouldn't depend on "dist" > to get the fan-out effects, and fan-out can be more selectively controlled. > - Untangle whatever our double-build is caused by; at first blush, it > seems to think my directories are out of date relative to the existing jar > (not the files in them, but the directories themselves). > - Change the default target to "dist," for back compatibility, since > that's what build today really does (build depends on -do which depends on > dist which depends on build in all the subprojects). > - Twiddle the semantics of "build" to be just building. I haven't > decided whether that would include building samples (probably; buildonly > exists to skip that), but it wouldn't assemble the distro archive and then > unpack it as dist does. > - Introduce user/test_dollar and user/test_underbar as java-root > directories with the obvious subset of files from today's user/test, and an > adjustment to the test target one or the other is on classpath, controlled > I > think by a system property. > > Thoughts on that? > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
