More generic form of uptodate - was: IDL compilation with ant -> problem?

[Marvin Greenberg <MG...@Eidea.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>-----Original Message-----
>From: G Ramasubramani [ mailto:grama@aztec.soft.net]
>Sent: Thursday, December 28, 2000 5:36 AM
>To: ant-user@jakarta.apache.org
>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
requires
totally parsing the IDL and is thus an annoyingly complex task to have to
write,
and becomes even more complex in order to be able to support different
implementations
of idl2java (because of different rules about where files are generated,
etc.).

I've developed a simpler approach that depends on the idl following some
known structure, and extending the uptodate task.  The modifications are
attached
with an example build file excerpt below.  The changes are based on the 1.3a
Ant
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
source,
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
causes
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
modifying
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="generated.java.root"
value="${idl.java.out}/${stub.dir}/${idl.module}" />

  <target name="idl2javacheck" >
    <mkdir dir="${generated.java.root}" />

    <uptodate property="idl2java.uptodate" >
       <srcfiles id="idl.files" dir="${idl.root}" includes="APEC.idl" />
       <targetfiles id="generated.java.files" dir="${generated.java.root}"
includes="**/*.java" />
    </uptodate>
  </target>
  
  <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="${idl.java.out}" />
      <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" />
    </execon>
  </target>




-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOk0VSeZodTRvTViVEQLsKgCdErnHSJMxq0CcbdFOhQ/i2nvaPEQAoPwQ
7KVsRlqGHJ6QVTVZz/o9r8CR
=XWf8
-----END PGP SIGNATURE-----


Re: More generic form of uptodate - was: IDL compilation with ant -> problem?

[James Duncan Davidson <du...@x180.net>]

On 12/29/00 2:50 PM, "Marvin Greenberg" <MG...@Eidea.com> wrote:

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

Currently Ant at core doesn't have the notion of update -- just Tasks to be
executed and all Tasks determine their own destiny. However, it's pretty
clear that a library of functionality could be made available to Task
writers to simplify things. Something along the lines of creating an
internal set of files (mapped original-->derived), letting the library do
some fancy MD5 hashing -- and then being able to come back to that on a
later run and get a list of files that are out of date. The question is how
is the best way to expose that functionality.

Right now, it's just thoughts that are going around on the dev list, but...

.duncan

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()