harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [buildtest] Proposal for Build Test Infrastructure Improvement
Date Fri, 20 Apr 2007 03:52:04 GMT
On 4/19/07, Alexander Kleymenov wrote:
> Stepan,
>
> On 4/19/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> >
> > Do we have suites with set of dependencies other then the following:
> > 1) classlib - no dependencies
> > 2) drlvm - depends on classlib only
> > 3) all other suites - depends on classlib and drlvm
> >
> > If no then ant code that manages dependencies between suites looks
> > redundant for me.


Hi Alexander,

>
> There can be a HDK building test suite, so all of the suites depending
> on drlvm will depend and on this test suite. And there can appear
> another dependencies between the suites.
>

This is not clear for me: currently there is no hdk suite. Could you
give more info?

> The test-suite dependency managing is a simple and quite natural way to
> define the relationships between the suites.

It is quite big peace of code. And I'm just trying to understand
whether we really need this functionality. If it is used only to
resolve suites dependencies on classlib and drlvm then I'd substitute
it with something that more simple.

BWT, how the framework resolves cycle dependencies?

> The information on such a
> relationships is very useful during the test run setup and execution
> stages. The resolution of default values for required parameters is
> dependent on this information, the order in which the selected test
> suites will be run (for single and CC run) is determined by means of
> this information, CC related functionality uses dependency info to
> retrieve SVN modifications lead to test-suite execution.
>
> So test-suite dependency management is an important architectural part
> of the proposed BTI. It can't be simply removed from the system. Can you
> suggest substitution for it?

My current view that the most of suites just need to know where is JRE
for testing.
Then the framework can do the following
1) if classlib is specified then test.jre.home=${classlib}/deploy/jdk/jre
In this case the framework user should just place VM implementation to
${classlib}/deploy/jdk/jre/bin/default. (for example, it may be IBM
VME). So the framework first rebuild classlib and then runs other
suites.

2) if classlib+drlvm are specified then
test.jre.home=${drlvm}/build/deploy/jdk/jre
In this case the framework first rebuild classlib, then drlvm suite
and after that runs other suites.

3) classlib and drlvm are not specified. test.jre.home is specified by
framework user.

Does this work for you?

Thanks,
Stepan

Mime
View raw message