Re: [classlib][build] Improvements to build system
--- Alexey Varlamov <[EMAIL PROTECTED]> wrote: > Guys, > > I have a kind request for "test" target > customization: > 1) need ability to pass extra arguments to tested > jre. This is useful > for testing various configurations of VM, e.g. > different execution > engines in DRLVM. you mean like passing nested and to ? These are available. > 2) easy switching between fork modes "perTest" & > "once". This is > actual for testing unstable VMs. So just use a junit.forkmode property defaulted to "once" and overridable with -D from the command line. Another popular strategy for using user-specific setup is to have your buildfiles attempt to load a properties file by a well-known name early on (first thing): If the file does not exist, no harm, no foul. If it does exist it is a convenient place to override default property settings. -Matt > > Or I'm just not aware of smth? Hmm, seems we can use > "harmonyvm.properties" to workaround item 1) ... > > -- > Alexey [SNIP] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] Improvements to build system
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 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]
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]
Re: [classlib][build] Improvements to build system
Guys, I have a kind request for "test" target customization: 1) need ability to pass extra arguments to tested jre. This is useful for testing various configurations of VM, e.g. different execution engines in DRLVM. 2) easy switching between fork modes "perTest" & "once". This is actual for testing unstable VMs. Or I'm just not aware of smth? Hmm, seems we can use "harmonyvm.properties" to workaround item 1) ... -- Alexey 2006/10/2, Oliver Deakin <[EMAIL PROTECTED]>: 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 > ok, Ill look out for these and replace them where I can. > 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. > yup, that sounds right - most of the modules already take care of their dependencies individually, tools should be no different. > 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 > Do you have any ideas about how we could do this? We have the added complication of the luni module having two native build targets that need to be called at different stages during the build. I had imagined a system where each module has knowledge of the dependencies for it's native code (luni would have two sets of deps). The top level build.xml would call each module in turn, and if that module finds that it's dependencies have already been built, it will go ahead and compile it's libraries. The top level build.xml would make multiple cycles through the set of modules until all have completed building, or the build has failed. However, I'm not sure this is possible in Ant. Ideas? > 5) Modular building and testing with an hdk? > Once (1) is complete this should be possible with an HDK placed into the deploy directory. i.e. you should be able to unpack an hdk into the deploy directory, and then build, rebuild and test in a modular fashion using -Dbuild.module. I still have the build target work (described at the bottom of [1]) in my todo list - I think this will be more useful once (1) is finished. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html > 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] > > > -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe,
Re: [classlib][build] Improvements to build system
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 ok, Ill look out for these and replace them where I can. 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. yup, that sounds right - most of the modules already take care of their dependencies individually, tools should be no different. 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 Do you have any ideas about how we could do this? We have the added complication of the luni module having two native build targets that need to be called at different stages during the build. I had imagined a system where each module has knowledge of the dependencies for it's native code (luni would have two sets of deps). The top level build.xml would call each module in turn, and if that module finds that it's dependencies have already been built, it will go ahead and compile it's libraries. The top level build.xml would make multiple cycles through the set of modules until all have completed building, or the build has failed. However, I'm not sure this is possible in Ant. Ideas? 5) Modular building and testing with an hdk? Once (1) is complete this should be possible with an HDK placed into the deploy directory. i.e. you should be able to unpack an hdk into the deploy directory, and then build, rebuild and test in a modular fashion using -Dbuild.module. I still have the build target work (described at the bottom of [1]) in my todo list - I think this will be more useful once (1) is finished. Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html 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] -- 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]
Re: [classlib][build] Improvements to build system
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]
Re: [classlib][build] Improvements to build system
On Sep 29, 2006, at 8:14 AM, Oliver Deakin 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. Yay! +1 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. Ok. +0 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? Regards, Oliver -- 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]
Re: [classlib][build] Improvements to build system
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]
[classlib][build] Improvements to build system
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? Regards, Oliver -- 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]
