harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject [general] New dependency for ant/lib (was Re: [drlvm][classlib unit tests] iterative runs)
Date Tue, 28 Nov 2006 13:18:03 GMT
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 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

View raw message