harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] New dependency for ant/lib (was Re: [drlvm][classlib unit tests] iterative runs)
Date Tue, 28 Nov 2006 18:10:07 GMT
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. <geir@pobox.com> 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
>

Mime
View raw message