Geir, Let me continue here.
As far as I understand the main purpose of build.bat script is to set Microsoft compiler environment for Windows using a standard environment setter vsvars32.bat. build.sh appeared for symmetry. Class path modification can be coded in ant via exec()/<exec> approach. Ant already forks in DRLVM build to download ant-contrib package first, and then dynamically link to it. If we choose forking approach for a class library copying a compiler to $ANT_HOME/lib and being squeamish will no longer be required. As for your question about <junit> clone, I was not precise in my statement. I believe we can extend org.apache.tools.ant.taskdefs.optional.junit.JUnitTask by our task, and for this apprach ant binary is more than enough. -- Thank you, Alexei On 11/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
This thread and some other thoughts I have banging around in head (like how to get rid of "build.sh" in DRLVM) is really a subject for everyone, not DRLVM. A) The iterated unit test approach has shown lots of benefit, and we'd like to add it as at least some kind of option to the build system, so that CI systems can invoke a classlib unit test run (and DRLVM unit test run) iteratively in the same VM. The simplest solution is the ant-contrib "for" loop, but IIRC, this needs to be either on the classpath or in ant/lib. B) The DRLVM build system requires a bat/sh to launch ant, to achieve the same purpose - to preload a bunch of stuff onto the classpath. First question - is there a way to dynamically add via cmdline or -ish things to the classpath for ant? (Paging Matt Benson...) Second - if not, can we do the equiv of an exec() with ant ? create a 'top level' build.xml that when invoked, fixes up the classpath and re-invokes ant using the new classpath, passing through all command line params and targets? Finally - if we can't do anything like this, does anyone mind if we create additional detritus in ant/lib like we do with ecj.jar? We can make it automatic, I suppose, but I'm always squeamish about dropping stuff into ant/lib geir Geir Magnusson Jr. wrote: > Sorry - I missed this yesterday for some reason > > Alexei Fedotov wrote: >> Geir, >> >> I support your point - a developer who resolves an intermittent issue >> needs a painless way to check his resolution. > > That, and we need to see if we are creating new intermittent issues. > >> >> I see two ways to implement it: >> * Automatically generate a build script: Egor posted me a feedback >> that it is not quite readable approach. > > I thought of this, and figure it's our last resort. > >> * Use <for> ant-contrib task: this adds ant-contrib dependency to the >> class library build system. > > Sure - but can we make that optional? No... I guess not. > >> * Make a clone from <junit> task: this adds a dependency from ANT >> source base. > > Source? Doesn't it just add a dep on the ant binary for building our tool? > >> >> All, >> Before starting a patch discussion let me ask which of three do you >> think is a better approach? >> > > This is buried here... this needs a new thread... > > geir
