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 Thu, 02 Nov 2006 15:02:49 GMT

I actually was serious. Probably you were confused, I didn't write 
"build test", I wrote "build smoke.test". The first one works ok, the 
second doesn't.

It happens because "test" (top-level test target) is handled in a 
different way from "smoke.test" (target just for smoke test category) 
target in build.xml. The "smoke.test" target just switches default 
processing target to "smoke.test" and runs "process_components" (which 
in its turn loops over all components). The "test" special handling of 
processing components escapes me, I don't quite understand how it works, 
but it seems to work correctly, without looping.

The question I was trying to solve was, how to correctly add jvmti.test 
target to the build.xml so that it would run only jvmti tests but not 
loop over components, but when "test" target it called, jvmti tests 
category would be executed along with all other categories.

Including "jvmti.test" target into build.xml in the same way as 
"smoke.test" doesn't make me happy.

Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
>> Geir Magnusson Jr. wrote:
>>> Why not use junit?
>> If you mean why not use junit to loop over tests, then it is not the 
>> case. I've used junit to do this in my work.
>> The loop which I wrote here is the loop over components in the 
>> build.xml of drlvm. If you run "build smoke.test" you'll see that the 
>> same tests are repeated several times (you have to be patient to see 
>> this).
> You're joking, right?  I do this for ever patch commit I do.
>> This is done because build loops over all known VM components like 
>> vmi, vmocode, gc, interpreter, etc. It is Ok for building, and it is 
>> done exactly for building, but it is not Ok for testing because 
>> repeating tests for the whole JVM for each of its components makes no 
>> sense.
> You're joking here too, right?  How do you know if there aren't side 
> effects among components?
> geir
>>> Gregory Shimansky wrote:
>>>> On Wednesday 01 November 2006 19:48 Alexey Varlamov wrote:
>>>>> Gregory,
>>>>> I observed similar quirks with paths while intergrating kernel tests
>>>>> into build. AFAIU the "Grand Design" is the following: there are
>>>>> abstracted targets and isolated component descriptors; build system
>>>>> iterates through all components and tries to apply given target to
>>>>> each component. So there are various tricks to stop it running tests
>>>>> multiple times a-la "recurring inclusion protection" in C headers.
>>>>> I do not grok how it calculates dependencies though, but it is quite
>>>>> easy to drive it mad and it starts doing wrong sequence of targets and
>>>>> picks wrong components etc.
>>>>> So I just snipped off that fanciful machinery and made simple subant
>>>>> for "kernel.test" target - see its definition in build/make/build.xml,
>>>>> and compare with nearby "smoke.test" one.
>>>> Ok I've made it though all of the interesting ant tricks and created 
>>>> my own jvmti.test target. I noticed the difference of how 
>>>> kernel.test target is included into build.xml as compared to 
>>>> smoke.test or unit.test.
>>>> AFAIU only "test" target does actually work to run only once and for 
>>>> the required number of modes (jit, interpreter). This is done with a 
>>>> special workaround for "test" target in build.xml, it has its own 
>>>> processing. But inclusion of smoke.test and unit.test in build.xml 
>>>> right now makes it run in a loop for all components for which tests 
>>>> don't have any relation to.
>>>> I am still experimenting with the build, it might be I'll find a 
>>>> solution for individual test categories so it would be possible to 
>>>> run them separately from the general "test" target.


View raw message