Separate tool. If the ant files that you start with are different than the ones at the revision you're asking for, do you really want the ant launched in the first revision-space to be driving?
On Wed, May 27, 2009 at 2:59 PM, Isaac Truett <[email protected]> wrote: > > +1 for Fred's use case. > > And bonus points if I can specify an SVN revision at the command line > and have it check out that revision and build it in one step. > > ... on second thought, that might be more appropriate for a tool > separate from the build script, but I'll throw it out there anyway. > > - Isaac > > On Wed, May 27, 2009 at 2:51 PM, Fred Sauer <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
