harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib][build] exclude list impl issues
Date Wed, 17 Jan 2007 12:55:33 GMT
> Well, my guess is that run-test targets are indeed custom in most
> modules, and partially due to lack of exlcude lists untill recently.
> Anyway, I don't think providing and utilizing common constructs really
> hurts customization flexibility.

I agree that "copy-pasting on demand" is a better slogan than just
"copy-pasting". But I think if we decide to refactor current build
system - extract common parts and use macros we should do it carefully
and apply our decision to all targets step by step.

> Yep, there is dedicated task for this, <available>.

You've probably seen that - I was using it in my example :)

> Actually, one can
> consider such warnings as hints - e.g. they helped me to catch the
> issue with "hy.test.vm.name" more easily.

Yes, to catch this kind of issues. But if the build really fails and
you are looking for the real issue such warnings can distract you.
There will be much more of such warnings when all modules will be
processed.

> So it is possible to
> simplify 4 targets to 1 like this:

Nice, it is shorter. However, it doesn't solve the missed-file-warning
issue described above.

With Best Regards,

2007/1/17, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> 2007/1/17, Alexei Zakharov <alexei.zakharov@gmail.com>:
> > Hi Alexey,
> >
> > > I've some concerns with recent updates for x-list support: can we use
> > > a common macros instead of copy-pasting 4 new targets into build.xml
> > > for each module?
> >
> > I can't say I enjoyed copy-pasting this stuff to all build.xmls but
> > AFAIU redundancy is a *feature* of the the current build system.
> > Almost all targets in all build.xml (build.xml local to each module I
> > mean) can be replaced with respective macro call and it should greatly
> > reduce the size of build files. But this seems to be a different
> > approach that has its own pros and cons. IMHO the advantage of the
> > current copy-pasted variant is that build files can be customized
> > easily and rapidly to suite the particular module needs.
> > BTW, it would be nice if the original build system author (Mark?) can
> > comment on this.
>
> Well, my guess is that run-test targets are indeed custom in most
> modules, and partially due to lack of exlcude lists untill recently.
> Anyway, I don't think providing and utilizing common constructs really
> hurts customization flexibility.
> And I'm interested to hear build gurus, too.
>
> >
> > > Also, I suggest to delete empty x-list remained after introducing common lists.
> >
> > IMHO it is convenient to have an empty file because it is much easier
> > to add something to already existent file rather than search through
> > the build.xml trying to understand what is the name of the file you
> > need to create. Or at least we need to place a file-name-hint
> > somewhere. I'm ok with both options.
> Hmm, until we are going to create empty files each time new platform
> or VM added, we better stay consistent from the beginning and drop
> empty files. Personally, having to inspect such files to see if there
> are no specific excludes bugs me much more than neccessity to read a
> FAQ once and for all.
>
> >
> > The real problem I currently see is the fact that Linux build prints
> > warnings then it tries to load an unexistent file via <loadfile>. I
> > see two solutions here. The first one is to create all empty files
> > including .interm exclude lists (that have good chanses to be empty
> > for all time). Another solution is to fix the build like this:
>
> Yep, there is dedicated task for this, <available>. Actually, one can
> consider such warnings as hints - e.g. they helped me to catch the
> issue with "hy.test.vm.name" more easily. So it is possible to
> simplify 4 targets to 1 like this:
>
> <target name="prepare-exclude">
> <loadfile property="common.x.content" srcFile="${common.x.file}"
> failonerror="false" />
> <property name="common.x.content" value=""/>
> <loadfile property="platform.x.content" srcFile="${platform.x.file}"
> failonerror="false" />
> <property name="platform.x.content" value=""/>
> <echo file="${exclude.file}"
> message="${common.x.content}${line.separator}${platform.x.content}"/>
> </target>
>
> >
> >    <target name="-init-exclude" >
> >        <echo message="" file="${exclude.file}" />
> >        <available property="jndi.common.exclude.exist"
> > file="${jndi.common.exclude.file}"/>
> >        <available property="jndi.platform.exclude.exist"
> > file="${jndi.platform.exclude.file}" />
> >        <available property="jndi.interm.exclude.exist"
> > file="${jndi.interm.exclude.file}"/>
> >    </target>
> >
> >    <target name="-add-common" if="jndi.common.exclude.exist" >
> >        <loadfile property="jndi.common.exclude.content"
> > srcFile="${jndi.common.exclude.file}" failonerror="false" />
> >        <echo message="${jndi.common.exclude.content}${line.separator}"
> > file="${exclude.file}" append="true" />
> >    </target>
> >
> >    <target name="-add-platform" if="jndi.platform.exclude.exist" >
> >        <loadfile property="jndi.platform.exclude.content"
> > srcFile="${jndi.platform.exclude.file}" failonerror="false" />
> >        <echo message="${jndi.platform.exclude.content}${line.separator}"
> > file="${exclude.file}" append="true" />
> >    </target>
> >
> >    <target name="-add-intermittent" if="jndi.interm.exclude.exist" >
> >        <loadfile property="jndi.interm.exclude.content"
> > srcFile="${jndi.interm.exclude.file}" failonerror="false"/>
> >        <echo message="${jndi.interm.exclude.content}${line.separator}"
> > file="${exclude.file}" append="true" />
> >    </target>
> >
> >
> > > Another issue is with "hy.test.vm.name", it was a surprise for me that
> > > it is not autodetected yet. Most obvious way to get it is to read
> > > "java.vm.name" property, this only requires running trivial test.
> >
> > +1 for autodetecting this if possible
> >
> > Regards,
> >
> > 2007/1/16, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
> > > Folks,
> > >
> > > I've some concerns with recent updates for x-list support: can we use
> > > a common macros instead of copy-pasting 4 new targets into build.xml
> > > for each module?
> > > Or, if we can neglect creating a compiled x-file
> > > (${hy.hdk}/build/<module>.exclude), just use "if" attribute of
> > > <excludesfile>, like this:
> > >
> > > <available property="x.list.exist"
> > > file="exclude.${hy.platform}.${hy.test.vm.name}"/>
> > > ...
> > >             <batchtest>
> > >                 <fileset dir="${src.test.java}">
> > >                     <include name="**/*Test.java"/>
> > >                     <excludesfile name="exclude.common"/>
> > >                     <excludesfile name="${exclude.file} if="x.list.exist"
/>
> > >                 </fileset>
> > >             </batchtest>
> > >
> > > Also, I suggest to delete empty x-list remained after introducing common lists.
> > >
> > > Another issue is with "hy.test.vm.name", it was a surprise for me that
> > > it is not autodetected yet. Most obvious way to get it is to read
> > > "java.vm.name" property, this only requires running trivial test.


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message