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 Tue, 17 Apr 2007 09:19:24 GMT
On 4/17/07, Alexander Kleymenov wrote:
> 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.
>

I'd like to have both of them :-)

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

As far as I remember the solution was to increase the max memory used
by Ant with setting ANT_OPTS to "-Xms256M -Xmx512M". Have you tried
this?

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

Well, I think we can fix this latter.

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

What kind of failure processing it does?

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

OK. I'll continue reviewing and if I find that it possible to avoid
using it I'll let you know.

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

Oops ... does it mean that this workaround binds the infra to selected
ANT version (in our case 1.6.5)? For example, if I have Ant 1.7
installed the infra won't work?

Also ... I wonder why we haven't meet this issue in classlib or drlvm
builds yet? It might mean that we use this Ant bug as a feature and
once Ant get fixed ... need to check classlib and drlvm.

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

Sorry, I didn't catch about proposed infra positioning. Could you clarify?
BTW, if we rename build.xml=>buildtest.xml we have to type each time:
ant -f buildtest.xml.

Thanks,
Stepan.

Mime
View raw message