harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Date Fri, 11 May 2007 13:23:02 GMT
> The original developers of the C unit test must
> have had some way of running individual tests.  Maybe they can donate this
> scripting code??

This can take too long time to wait for them. For now I've added new
top level target "cunit.test" at r537186. The test run take less than
two minutes on my machine. Please check if it solves your problem.

Regards,

2007/5/10, Weldon Washburn <weldonwjw@gmail.com>:
> On 5/10/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> >
> > Hi Weldon,
> >
> > You've got wrong impression somehow, ehwa and cunit tests have
> > absolutely no relation and/or dependency. Currently cunit tests are
> > part of the top-level joint target "test", but I have no idea why
> > there is no standalone target for them.
>
>
> Most likely I am confused by the testing scripts.  I really do not
> understand them.
>
> Another point, do your tests really fit into unit testing concept?
>
>
> Actually, its not my tests.  The problem is that the existing tests fail to
> link when I add a call to gc_force_gc() from the Thread Manager code.
> Somehow I need to add an empty gc_force_gc() { } stub to the C unit test
> framework.  But first I would like a quick way to run the C unit tests.
>
>
>  If
> > they involve several components, maybe just put them into different
> > suite?
>
>
> hmm... it would be nice to avoid rewriting  the C unit thread tests.  Maybe
> there is a simpler way.  The original developers of the C unit test must
> have had some way of running individual tests.  Maybe they can donate this
> scripting code??
>
> 2007/5/9, Weldon Washburn <weldonwjw@gmail.com>:
> > > On 5/9/07, Alexei Zakharov <alexei.zakharov@gmail.com> wrote:
> > > >
> > > > Hi Weldon,
> > > >
> > > > Looks like you can't do exactly what you want with current build
> > > > scripts. Or at least I don't know an easy way. I suppose we can add a
> > > > top-level target like thread.test for running these tests separately
> > > > if you think it makes sense.
> > >
> > >
> > > How soon can thread.test be added?  It turns out that I need to be able
> > to
> > > call gc_force_gc() from jthread.lib.  The cunit.test fails because
> > > jthread.lib hits an unresolved external reference (gc_force_gc) when
> > linking
> > > with the cunit test framework.  This should be an easy thing to fix once
> > the
> > > build/test cycle is shortened.  The current build/test cycle for "build
> > > ehwa.test" is more than 20 minutes currently.
> > >
> > > Looking at the big picture, what did the original test developers do to
> > > solve the above problems?  Maybe this code has already been developed
> > and
> > > simply not yet donated??  Does anybody know?
> > >
> > >
> > > Regards,
> > > >
> > > > 2007/5/8, Weldon Washburn <weldonwjw@gmail.com>:
> > > > > All,
> > > > > From "build test2" output, it looks like cunit.test is called
> > > > (indirectly)
> > > > > by ehwa.test.  "build ehwa.test" works fine but takes a really long
> > time
> > > > to
> > > > > run.  I would like to quickly run just the tests located in the
> > > > > working_vm/vm/tests/unit/thread directory.  Can the build experts
> > give
> > > > > suggestions on how to do this.
> > > > >
> > > > > Thanks


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message