harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Date Tue, 14 Nov 2006 18:31:44 GMT

Gregory Shimansky wrote:
> 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?

Hey, the work is done :)

The fact is, you can still have a dependency in init and setup to get 
the goodness from there.

I hope to look at this on the plane home tonight.

>>> 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.

We decided that last may, didn't we?



View raw message