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 Thu, 02 Nov 2006 18:00:30 GMT

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

I've used them both, and targetted smoke for specific use cases (opt, etc)

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

Right - I thought you'd start a revolt and do it outside of the "loop 
over test types" system we have now.

In order to keep this simple, why not just have a separate test target 
for now

     $ sh build.sh test.jvmti

and we can stare at that together, and figure out how to integrate... 
simplest thing would be to rename the current "test" target to 
"test_loop" or something, and then

   <target name="test" depends="test_loop, test.jvmti" />



> 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