I have not. I've gone treasure hunting a couple of times, but did not find a good build target. I'll give buildonly a try. (On my system (Vista :<) creating the zips for the ditros actually takes some time. Building the jars for the two platforms I don't need (at that moment at least) also takes time that would be nice to avoid. Anyway, I'll try buildonly.
Thanks Fred On Wed, May 27, 2009 at 11:46 AM, Freeland Abbott <[email protected]>wrote: > I think that's about what I'm hoping to make "ant build" become. > > In terms of what's there today, Fred, have you tried the existing top-level > "buildonly" target? My complaint with that one is that it doesn't get the > .so/.dll files into a usable place, but if you manually drop them into > build/lib, I think it's the closest we have today. > > > > On Wed, May 27, 2009 at 2:34 PM, Fred Sauer <[email protected]> wrote: > >> My pain point: >> I often want a trunk build of GWT to quickly test a patch. In this case I >> only need the GWT build for the current platform whatever that is. I don't >> need samples/demos nor do I need/want tests. I don't need a zipped up >> distro, just the jars. Even javadocs would be optional. Of course I want all >> of that and be able to do incremental builds. >> >> I imagine something like this: >> >> 1. ant clean platform-jars >> 2. (make a small code change to GWT compiler and/or GWT widgets) >> 3. ant platform-jars (fast, incremental build) >> >> Fred >> >> On Wed, May 27, 2009 at 10:38 AM, Freeland Abbott <[email protected]>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? >>> >>> >>> >> >> >> -- >> Fred Sauer >> Developer Advocate >> Google Inc. 1600 Amphitheatre Parkway >> Mountain View, CA 94043 >> [email protected] >> >> >> >> > > > > -- Fred Sauer Developer Advocate Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 [email protected] --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
