ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Greenberg <>
Subject More generic form of uptodate - was: IDL compilation with ant -> problem?
Date Fri, 29 Dec 2000 22:50:48 GMT
Hash: SHA1

>-----Original Message-----
>From: G Ramasubramani []
>Sent: Thursday, December 28, 2000 5:36 AM
>Subject: Re: IDL compilation with ant -> problem?
 >I suppose instead of calling execon, you will have to write your own
>task which shall internally generate the dependancies and check the
>time-stamps to decide which idl to compile and which not to.

- ----
The only problem with this is that to determine dependencies for IDL
totally parsing the IDL and is thus an annoyingly complex task to have to
and becomes even more complex in order to be able to support different
of idl2java (because of different rules about where files are generated,

I've developed a simpler approach that depends on the idl following some
known structure, and extending the uptodate task.  The modifications are
with an example build file excerpt below.  The changes are based on the 1.3a
code base.  They add to "uptodate" the ability to compare two different
FileSets.  If ALL the files in the target Fileset are newer then ALL in the
then it is up-to-date.  Since IDL tends to be more stable than source code,
this allows the build to only rebuild all the IDL when necessary.  If you
change one
IDL file it will regenerate it all.  There is a special case for this
uptodate test:
if the passed target Fileset has no elements, uptodate will also fail.  This
the correct behavior when nothing has been generated yet.

The biggest drawback to using this approach is that it isn't part of Ant, is
files that are part of Ant and may have to be redone with new releases of
Ant.  It would
be simple to just write a totally new task "newuptodate" to avoid that
problem.  I'm hoping
someone on the core Ant development team sees some validity to the more
general uptodate.
It also doesn't give IDL file level granularity -- I wrote a mapper that did
some similar things,
but since I would then also have to write a separate idltojava Task to use
the mapper, it
seemed not worth the effort.

   <!-- I know that all my generated code will be under a root directory for
a particular idl
module -->
  <property name=""
value="${}/${stub.dir}/${idl.module}" />

  <target name="idl2javacheck" >
    <mkdir dir="${}" />

    <uptodate property="idl2java.uptodate" >
       <srcfiles id="idl.files" dir="${idl.root}" includes="APEC.idl" />
       <targetfiles id="" dir="${}"
includes="**/*.java" />
  <target name="idl2java" depends="idl2javacheck" unless="idl2java.uptodate"
    <execon executable="${vbroker.home}/bin/idl2java.exe" parallel="true" >
      <arg value="-package" />
      <arg value="${stub.package}" />
      <arg value="-root_dir" />
      <arg value="${}" />
      <arg value="-Id:/Cvsdir/Svc/IDL" />
      <arg value="-idl2package dec com.eidea.dec.stub" />
      <arg value="-no_comments" />    <arg value="-no_examples" />

      <fileset refid="idl.files" />

Version: PGPfreeware 6.5.8 for non-commercial use <>


View raw message