harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Kleymenov" <kleyme...@gmail.com>
Subject Re: [buildtest] Proposal for Build Test Infrastructure Improvement
Date Fri, 20 Apr 2007 05:42:42 GMT

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

I'm not telling about the facts, but about possibilities here.
Such a suite can arise, and BTI should handle new dependencies without
need to be reimplemented.

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

It should report an error. Now it just cut the circle.

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

No, there are other things. For example - to run classlib unit tests we
define test suite 'classlib-test' which depends on 'classlib' suite.
All we need to do to implement 'classlib-test' is to define the dependency on
'classlib', use its shared 'trunk.dir' parameter as a default for
'built.classlib.workspace' required parameter, and write single line in
adaptor's run target:
    <ant dir="${built.classlib.workspace}" target="test"/>
It's quite simple and natural solution in the current BTI approach
with dependency management means presented.

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

I think we should keep the general approach to dependency management and
do not tie with particular intersection points (I mean tested jre in
your case).
I think we should keep the information about such intersections on the
level of test suites (as it's done now). In the current approach the
appearance of a new test suite with the product which can be shared does
not cause the fixes inside the framework. In your case such a new
'shared' product causes drilling into framework.


View raw message