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 07:03:23 GMT
On 4/20/07, Alexander Kleymenov wrote:
> Hi,
> > > 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.

Sorry for being persistent - I don't understand about which
possibilities you are talking about. Could you describe how suites'
drlvm-dependency is resolved in case of hdk suite only ? Also how the
framework resolves the dependency if there are classlib+drlvm+hdk all
together? And what if I want to run suites on classlib+IBM VME?

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

But currently there is no 'classlib-test' suite for the proposed infra ...

> 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"/>

Right. And the current infra does this without a need to build a tree
of suites dependencies and traversing the tree to optimize it by
looking for cycles and unselected nodes. Again could give an example?
We mentioned hdk suite above. It might be a perfect real case to
demonstrate new functionality.

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

No drill into the framework is required - the suite implements
ant-targets to set-up it, run it and publish its results. And the
framework provides to the suite a location of JRE to run its tests. I
want just keep things simple.


View raw message