ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: Generating java files selectively from IDL files using <depen d> a nd <mapper> type glob
Date Fri, 30 Jan 2004 18:16:30 GMT
Dominique Devienne wrote:

>>From: Peter Reilly [mailto:peter.reilly@corvil.com]
>>    
>>
>>>Does <outofdate> support setting the <targets> from the sources
>>>and a <mapper>? In the use case of a one-to-one mapping for example?
>>>
>>>
>>>      
>>>
>>Yes  - outputtargetspath sets a reference to a path that contains all
>>the targets
>>that need to be updated and alltargetspath sets a reference to a path that
>>contains all the targets.
>>Note that this is not very usefull as filesets cannot contain files that
>>do not exist and so <pathtofileset> in this situation will not make a
>>fileset
>>that contains targets that need to be created.
>>    
>>
>
>It doesn't really matter. The point is that you can just define the
><fileset> of your sources, for example all your Java classes you want
>to <javah> (I have a selector to find these), and a simple mapper of
>each equivalent generated .h files. I fear that <outofdate> probably
>checks all files and targets in one lump currently, instead of checking
>just one source/target tupple at a time though, as needed in my <javah>
>
>use case. I'm sure you can come up with a solution using <for>, but I
>
>prefer declarative solutions...
>  
>
No it takes each tupple at a time and populates the outputsourcepath if that
tupple is outofdate (this when using mapper and not a targetfiles 
element - in
the later case, each source is checked against all the targets).

For example:
suppose one had a task that took a javafile, a source dir and a dest dir and
generated a .cpp and a .h file in the destfile of the javafile relative 
to the
source file without timestamp checking.
One could write an outofdate script to invoke the task only
for javafiles that were outofdate:

        <ac:outofdate outputsourcespath="modified.sources">
          <ac:sourcefiles>
            <ac:fileset dir="${sourcedir}" includes="**/*.java"/>
          </ac:sourcefiles>
          <ac:mapper dir="${sourcedir}"
                     type="glob" from="*.java" to="${destdir}/*.cpp"/>
          <ac:mapper dir="${sourcedir}"
                     type="glob" from="*.java" to="${destdir}/*.h"/>
          <ac:sequential>
            <ac:for param="file">
              <ac:path refid="modified.sources"/>
              <ac:sequential>
                <gencpp
                  sourcedir="${sourcedir}"
                  destdir="${destdir}" javafile="@{file}"/>
              </ac:sequential>
            </ac:for>
          </ac:sequential>
        </ac:outofdate>


One could make that into a macrodef - well, one could if it did not
trigger a bug in MacroInstance (opps) caused (I think) by the multiple 
macrodef layers.

>Currently, I rely on a custom task for my 'smart' <javah> use case,
>but a generic solution would be nice... Although it's probably
>difficult to add generically other smarts like my tasks making sure
>the generated header is indeed modified to avoid too many C++ compiles
>when the native method signatures were not changed.
>
>But maybe you have an idea on how to do this generically? --DD
>  
>
no...
Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message