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 Tue, 17 Apr 2007 07:34:24 GMT
Hi Stepan,

Thanks for comments and your work with it!
Please, look at my responses bellow.

On 4/17/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> Hi Alexander,
>
> I've reviewed almost all the code. And I have some comments and questions:
>
> 1) Is it possible to add modules 'drlvm-test' and 'classlib-drlvm'
> that we have in the current infra? I'll help the difference between
> approaches.

I'll look at drlvm-test.
I think classlib-drlvm is the same as launching of the new BTI with
drlvm and classlib selected.

>
> For example, the following difference for classlib confuses me a
> little bit: the current infra launches classlib by simply calling
> classlib's build with corresponding target:
> <ant target="fetch-depends rebuild" ....
> </ant>
>
> But the proposed infra does the next: calls adaptor.xml with 'run'
> target (I'm OK with it). But the classlib's adaptor not just simply
> calls classlib's build. It detects OS, set corresponding properties,
> calls classlib's target 'fetch-depends' with <ant> and then calls
> classlib's target 'rebuild' via <exec> task. So we have, for example
> for Windows:
>        <ant target="fetch-depends" dir="${trunk.dir}"
>             inheritAll="false">
>        </ant>
>        <exec executable="cmd" dir="${trunk.dir}" failonerror="true">
>            <arg line="/c ${ant.home}/bin/ant.bat"/>
>            <arg line="rebuild"/>
>        </exec>
>
> What the reason for calling classlib's build in this way? Why we have
> to run 'ant.bat' (or 'ant.sh' for Linux) via <exec>?

It's workaround for Ant's OutOfMemory problem arising after doing the same
by <ant> target. The <ant>-rebuild of classlib project causes big memory
leaks somewhere in the Ant and the further BTI execution is impossible
becouse of arising OOM.

>
> 2) The build files have cyclic import dependencies:
> framework.xml => cc-project.xml => framework.xml
>
> It complicates the build logic. Is it possible to avoid this?

I agree, we should avoid such loops. Here it is implementation rather
than design issue, so it should not take much efforts and time.
Should I provide the fix for this?

>
> 3) In exec-adaptor.xml antconrib's wrapper 'trycatch' and 'runtarget'
> task are used for calling adaptor's(i.e. suite's) target.
>
> <trycatch property="execution.exception">
>    <try>
>        <runtarget target="@{target}"/>
>    </try>
>    <catch>
> Echo error message
>    </catch>
> </trycatch>
>
> Again, why it is not possible use <ant> task? And this leads to the
> next question.

Infra needs some failure processing means here. Default <ant> task does
not allow to do it. Using of <runtarget> instead of <ant> saves memory
as it does not fork the ant's project.

> 4) Using antcontrib. The proposed implementation uses it in many
> places. But from my POV it is possible to use ANT tasks/targets/macros
> instead. For example, I've picked up the first case from
> 'framework.xml' that patches ANT:
> <target name="patch-ant" depends="make-dirs, define-tasks">
>    <if>
>        <not><available file="${temp.files.dir}/SubAnt.java"/></not>
>    <then>
>        <get src="http://issues.apache.org/bugzilla/attachment.cgi?id=15681"
>             dest="${temp.files.dir}/SubAnt.java"
>             usetimestamp="true"
>             verbose="true"
>        />
>    </then>
>    </if>
> ...
> </ target >
>
> That IMHO can be easy converted to 'pure' ANT by creating target that
> only runs if there is no SubAnt.java file and adding the target to
> "patch-ant" decencies.

Yes, it's possible to rewrite this simple case. But such a notation
looks quite natural. And execution thread went to here assumes that
ant-contrib has already been installed. So I chose simple notation
rather than ant-contrib independent.

> Actually, I don't want to start flame war - which approach is better.
> I'm just trying to understand is it possible to avoid using antcontibs
> task? IOW, is there any issue that can not be solved by using ANT
> only?

I tried to implement the framework without ant-contrib but such a way
led to really complicated and unmaintainable code.
I thought 'why to reinvent ant-contrib' and started to use it.

> 5) Patching ANT - is there any workaround?

It's a workaround itself. For Ant's basedir problem. Ant does not set
basedir properly if <ant> task executes the code containing <subant>
task. This path is taken from the bug report filed on both versions of
ant. Here it's supposed that 1.6.5 version is used. To be more correct
here we should check current ant's version and take suitable patch.

> 6) And minor question: is there any strong reason for naming build
> scripts 'adaptor.xml' not 'build.xml'?

I'm positioning the BTI framework not as an Ant-based Build System,
but as an Application implemented in Ant Scripting Language.
In build systems build.xml is a self-documenting file name.
In BTI the name adaptor.xml does the same - it documents itself.
I think it would be better to rename root build.xml to buildtest.xml.

Thank you,
Alexander

Mime
View raw message