You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2007/05/08 19:55:05 UTC
[drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
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
--
Weldon Washburn
Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Posted by Alexei Zakharov <al...@gmail.com>.
> 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 <we...@gmail.com>:
> On 5/10/07, Alexey Varlamov <al...@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 <we...@gmail.com>:
> > > On 5/9/07, Alexei Zakharov <al...@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 <we...@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
Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Posted by Weldon Washburn <we...@gmail.com>.
On 5/10/07, Alexey Varlamov <al...@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 <we...@gmail.com>:
> > On 5/9/07, Alexei Zakharov <al...@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 <we...@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
> > > >
> > > > --
> > > > Weldon Washburn
> > >
> > >
> > > --
> > > Alexei Zakharov,
> > > Intel ESSD
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> >
>
--
Weldon Washburn
Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Posted by Alexey Varlamov <al...@gmail.com>.
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.
Another point, do your tests really fit into unit testing concept? If
they involve several components, maybe just put them into different
suite?
2007/5/9, Weldon Washburn <we...@gmail.com>:
> On 5/9/07, Alexei Zakharov <al...@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 <we...@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
> > >
> > > --
> > > Weldon Washburn
> >
> >
> > --
> > Alexei Zakharov,
> > Intel ESSD
> >
>
>
>
> --
> Weldon Washburn
>
Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Posted by Weldon Washburn <we...@gmail.com>.
On 5/9/07, Alexei Zakharov <al...@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 <we...@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
> >
> > --
> > Weldon Washburn
>
>
> --
> Alexei Zakharov,
> Intel ESSD
>
--
Weldon Washburn
Re: [drlvm][build files] Does anyone know how to cause only cunit.test to be executed?
Posted by Alexei Zakharov <al...@gmail.com>.
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.
Regards,
2007/5/8, Weldon Washburn <we...@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
>
> --
> Weldon Washburn
--
Alexei Zakharov,
Intel ESSD