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]
