harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Date Mon, 13 Nov 2006 02:03:15 GMT
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
> > Ok I think I've come up with a reasonable compromise. I still used the
> > whole system of converting XML and all the stuff. It does quite a lot of
> > things in setup and init targets and using <select> is convenient. I
> > don't know how to untangle all of the setup and not do a lot of
> > duplication in ant scripting which I am not big expert in.
> Why?  Why do we want to persist with this system, when WE ARE GOING TO
> GET RID OF IT at some point?

One reason would be is that I don't know ant well enough to redesign the whole 
stuff all together. I used the existing setup and init targets which take 
care of including ancontrip and cctask jars.

If you ask me, I'd prefer make in the first place, ant is just too foreign to 
me. There is no reason to use caps, we didn't even start to discuss how we 
want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some 

> Did you also fix the silliness of having to use annotations to exclude
> tests?  Please? :)

No, the patch has an exclude example using and <exclude> statement in 
patternset in its beginning.

> I'm glad we have these tests, but really...  I wish you hadn't invested
> the time integrating it into the DRLVM build system...

Even if we write a new one from scratch I want the tests right now. There were 
several times when JVMTI was broken since there were no tests for it at all 
since it is a special VM mode no one usually uses.

The time invested, well... I learned a lot since the last time I used ant. 
Maybe one day I'll be able to write something as impressive and 
unmaintainable as the current drlvm built :)

Seriously, if we're going to change it, let's discuss it how we want it to 
look like and which tool we'll use. I vote for make (gnu version, that is 
gmake), even on win32 it exists in cygwin and mingw.

Gregory Shimansky, Intel Middleware Products Division

View raw message