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 15:34:44 GMT
Geir Magnusson Jr. wrote:
  > Gregory Shimansky wrote:
>> 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 point".
> The caps were to get your attention.  I thought you had a nice way to 
> create a standalone testbed and then hook that in.

Well as I've written already, there is very much that is done in setup 
and init targets of drlvm build. It is checking for necessary jar files 
like junit, ant-contrib, cctask. Also these targets setup a lot of 
necessary properties. I just didn't want to duplicate all of that stuff.

The fact that these targets (setup and init) also do XML transform is 
almost not used in jvmti tests. Yes there are 2 <select> which are 
processed in XML transform, but I can remove them when necessary. I 
consider this dependency on current drlvm build minor. If we decide to 
get rid of XML processing, the changes in jvmti tests build shall be 
minimal. Does it sound ok to you?

>> 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.
> I think that we should simply use the same tooling that we're using now 
> in classlib.

Ok let's decide that exactly we don't like in the current drlvm build. 
Probably I should start another thread.


View raw message