There are tons of enhancements and bug fixes between 1.6.5 and 1.7; that said, I haven't seen any issues in the build that I think require 1.7 to solve. If I get the time to take a look at the nested <ant> invocations bug before 1.7 comes out that might be a good reason to upgrade. I haven't been able to pay as close attention as I had planned; are there any major issues with the build that I have missed?
-Matt ----- Original Message ---- From: Oliver Deakin <[EMAIL PROTECTED]> To: harmony-dev@incubator.apache.org Sent: Tuesday, October 3, 2006 5:34:02 AM Subject: Re: [classlib][build] Improvements to build system I had a quick look at the Ant website - I can't see anything obvious in 1.7 that will make a big difference to us. Most of the information I found was concerned with antlibs. Anyone spotted anything we could use? Regards, Oliver Geir Magnusson Jr. wrote: > Also, should we update to ant 1.7? Any new features that could help? > > I know it's still in beta, but still... since you are about to > refactor, might be worth considering. > > geir > > On Sep 29, 2006, at 10:07 AM, Mark Hindess wrote: > >> >> On 29 September 2006 at 13:14, Oliver Deakin >> <[EMAIL PROTECTED]> wrote: >>> Hi all - Ive been away from the list this week, so sorry if Ive >>> missed a >>> few >>> mails. Ill try and get back to them as soon as possible. >>> >>> In the meantime Ive been thinking about the classlib build system, >>> and spotted a couple of things that Id like to fix/cleanup: >>> >>> 1) Although we can build a specific module with -Dbuild.module, >>> currently >>> we cannot just clean or rebuild a single module. I'd like to be able to >>> run "ant -Dbuild.module=luni rebuild" and have it clean only the luni >>> java and native binaries and rebuild them. Currently this call >>> results in >>> a total clean of all modules, and then all the native code being >>> rebuilt, >>> but only the java code for luni (so you end up with only luni.jar in >>> lib/boot)! It would also be nice to be able to use the new rebuild-java >>> and rebuild-native targets on a per module basis. >>> >>> 2) In the top level build script we have a number of "public" and >>> "private" targets (the "private" ones are prefixed by a hyphen so >>> that they cannot be run from the command line). However at the >>> modular level the build scripts do not have this separation of >>> external and internal targets, even though it is expected that >>> developers >>> may run these scripts directly. I would like to setup these scripts >>> in the >>> same way as the top level build.xml- with build, build-java, >>> build-native >>> etc. external targets and all others as internal and prefixed with >>> a hyphen. >>> >>> I notice that Mark has done some cleanup of the build scripts under >>> make recently, but I think the modular scripts still require tidying >>> up. >>> Does anyone have any objections to these? Any ideas of other >>> relevant activities I can carry out while Im in there? >> >> The other things I was thinking about were: >> >> 1) Replacing antcall tasks with task dependencies >> >> 2) Moving stuff out of the make/build-java.xml file to a module where >> there is an obvious module that these files should be associated >> with. For instance, the ant for moving the ecj.jar really belongs >> with the tools module - since if you aren't building the tools module >> you would not need that jar. >> >> 3) Fixing the way we build the test support jar too frequently - i.e. >> the fact that we delete it before we test even if it hasn't changed. >> >> 4) Whether we can make make/build-native.xml derive some information >> from the modules - which ones need calling in which order - rather >> than hard coding this information >> >> 5) Modular building and testing with an hdk? >> >> As usual, I'm sure I'll find more work when I start looking more >> closely. >> >> -Mark. >> >> >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Oliver Deakin IBM United Kingdom Limited --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
