Re: [Ant-contrib-developers] Little issue with <outofdate>

[peter r. <pet...@co...>]

Opps, I meant to say execute  once! ..... ;-)

In any case, I have updated outofdate to deal with <sourcefiles/>
by checking the existance of the target files.
With verbose you will get the message:
SourceFile null outofdate with regard to
/home/preilly/proj/learning/outofdate/NOT.PRESENT

I still think that your generated files depend on the build.xml, or
common.xml file, but I can see your problem. Still, common.xml
should not change too often.....

I had a similar problem years ago with generated files - the
source changed but the content of the genereated files did not
(for example it may be a list of exported functions in a dll). My perl
generator generated the files internally and only if they were different
did it update the generated files.

Cheers,

Peter

On Wednesday 23 April 2003 15:23, Dominique Devienne wrote:
> I thought you might say that, but in this case, the content of files wi=
ll
> never change anymore (for sure), and doing as you say would force the
> recompilation of *everything* since these headers are included (indirec=
tly)
> by everything. I very often change the common.xml XML entity included f=
or
> things unrelated to these two headers, and a one hour recompilation of =
500K
> lines of C++ as a consequence is simply unacceptable.
>
> I thus *really* think an empty <sourcefiles/> should be legal!
>
> I (heartily ;-) disagree with you about your fixing the 'bug' alternati=
ves:
> Whining dismisses my use case (which I persist is valid), and always
> executing <sequential> simply is wrong, since shouldn't be executed whe=
n
> the target files exits.
>
> I'd hate to be forced to fork <outofdate>. --DD
>
> -----Original Message-----
> From: peter reilly [mailto:pet...@co...]
> Sent: Wednesday, April 23, 2003 3:24 AM
> To: Dominique Devienne; ant...@li...
> Subject: Re: [Ant-contrib-developers] Little issue with <outofdate>
>
> I am not to sure I agree with your usecase.
> _undefs.h and _defines.h are generated files - but
> there are not generated out of thin air!.
>
> In this case they depend on the build.xml file, i.e. if
> the build.xml file changes (in particular the contents of
> <echo file =3D...></echo> in the <sequential/>) the target
> files need to be changed.
>
> I would (and have in my build files) do
> <outofdate>
>    <sourcefiles path=3D"build.xml"/>
>     <targetfiles>
> =09<...>
>     </targetfiles>
>      <sequential>
>         <.../>
>      </sequential>
> </outofdate>
>
> As regards targets that have no source dependencies, I will need to thi=
nk
> about it.
>
> The empty sourcefiles example does looks like a bug, either
> outofdate should whine, or always run sequential - I am not too sure wh=
ich!
>
> Cheers,
>
> Peter
>
> On Tuesday 22 April 2003 21:36, Dominique Devienne wrote:
> > I wanted to use <outofdate> like this:
> >     <outofdate>
> >       <targetfiles>
> >         <pathelement location=3D"${lib.defs.dir}/_undefs.h" />
> >         <pathelement location=3D"${lib.defs.dir}/_defines.h" />
> >       </targetfiles>
> >       <sequential>
> >         <echo file=3D"${lib.defs.dir}/_undefs.h">...</echo>
> >         <echo file=3D"${lib.defs.dir}/_defines.h">...</echo>
> >       </sequential>
> >     </outofdate>
> >
> > But was forced to use it like this:
> >     <outofdate>
> >       <sourcefiles>
> >         <pathelement location=3D"${lib.defs.dir}/enter_scope.h" />
> >       </sourcefiles>
> >       <targetfiles>
> >         <pathelement location=3D"${lib.defs.dir}/_undefs.h" />
> >         <pathelement location=3D"${lib.defs.dir}/_defines.h" />
> >       </targetfiles>
> >       <sequential>
> >         <echo file=3D"${lib.defs.dir}/_undefs.h">...</echo>
> >         <echo file=3D"${lib.defs.dir}/_defines.h">...</echo>
> >       </sequential>
> >     </outofdate>
> >
> > i.e. I was forced to put a dummy source file to make it work.
> >
> > Worse, I tried to do:
> >     <outofdate>
> >       <sourcefiles />
> >       <targetfiles>
> >         <pathelement location=3D"${lib.defs.dir}/_undefs.h" />
> >         <pathelement location=3D"${lib.defs.dir}/_defines.h" />
> >       </targetfiles>
> >       <sequential>
> >         <echo file=3D"${lib.defs.dir}/_undefs.h">...</echo>
> >         <echo file=3D"${lib.defs.dir}/_defines.h">...</echo>
> >       </sequential>
> >     </outofdate>
> >
> > (and removed the target files to force regeneration), and *nothing*
> > happened/was generated.
> >
> > I personally think that this use case is acceptable, i.e. when one ne=
eds
>
> to
>
> > generate files from nothing (out of thin air), one doesn't have a sou=
rce
> > file, but the generation process should nonetheless happen if the tar=
get
> > files are *not found*. I can live with being forced to have a
> > <sourcefiles />, although not having one at all seems fine to me, but=
 I
> > consider the current behavior of not executing the nested sequential =
when
> > a target file is not found and one has an empty <sourcefiles/> a bug.
> >
> > Let me know what you think. --DD
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Ant-contrib-developers mailing list
> Ant...@li...
> https://lists.sourceforge.net/lists/listinfo/ant-contrib-developers