From: Dominique D. <DDe...@lg...> - 2003-04-23 14:24:18
|
I thought you might say that, but in this case, the content of files will never change anymore (for sure), and doing as you say would force the recompilation of *everything* since these headers are included (indirectly) by everything. I very often change the common.xml XML entity included for 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' alternatives: Whining dismisses my use case (which I persist is valid), and always executing <sequential> simply is wrong, since shouldn't be executed when 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 =...></echo> in the <sequential/>) the target files need to be changed. I would (and have in my build files) do <outofdate> <sourcefiles path="build.xml"/> <targetfiles> <...> </targetfiles> <sequential> <.../> </sequential> </outofdate> As regards targets that have no source dependencies, I will need to think about it. The empty sourcefiles example does looks like a bug, either outofdate should whine, or always run sequential - I am not too sure which! Cheers, Peter On Tuesday 22 April 2003 21:36, Dominique Devienne wrote: > I wanted to use <outofdate> like this: > <outofdate> > <targetfiles> > <pathelement location="${lib.defs.dir}/_undefs.h" /> > <pathelement location="${lib.defs.dir}/_defines.h" /> > </targetfiles> > <sequential> > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > <echo file="${lib.defs.dir}/_defines.h">...</echo> > </sequential> > </outofdate> > > But was forced to use it like this: > <outofdate> > <sourcefiles> > <pathelement location="${lib.defs.dir}/enter_scope.h" /> > </sourcefiles> > <targetfiles> > <pathelement location="${lib.defs.dir}/_undefs.h" /> > <pathelement location="${lib.defs.dir}/_defines.h" /> > </targetfiles> > <sequential> > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > <echo file="${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="${lib.defs.dir}/_undefs.h" /> > <pathelement location="${lib.defs.dir}/_defines.h" /> > </targetfiles> > <sequential> > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > <echo file="${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 needs to > generate files from nothing (out of thin air), one doesn't have a source > file, but the generation process should nonetheless happen if the target > 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 |
From: Brad C. <bc...@bo...> - 2003-04-23 14:53:55
|
outofdate is a task designed to compare one set of files against another and react when there are conflicts. Your case seems to be that if either of two files don't exist you want to generate both of them. To me it would make a lot more sense as something like this: <if> <not> <and> <available file="${lib.defs.dir}/_undefs.h"/> <available file="${lib.defs.dir}/_defines.h"/> </and> </not> <then> <sequential> <echo file="${lib.defs.dir}/_undefs.h">...</echo> <echo file="${lib.defs.dir}/_defines.h">...</echo> </sequential> </then> </if> At 09:23 AM 4/23/2003, Dominique Devienne wrote: >I thought you might say that, but in this case, the content of files will >never change anymore (for sure), and doing as you say would force the >recompilation of *everything* since these headers are included (indirectly) >by everything. I very often change the common.xml XML entity included for >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' alternatives: >Whining dismisses my use case (which I persist is valid), and always >executing <sequential> simply is wrong, since shouldn't be executed when 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 =...></echo> in the <sequential/>) the target >files need to be changed. > >I would (and have in my build files) do ><outofdate> > <sourcefiles path="build.xml"/> > <targetfiles> > <...> > </targetfiles> > <sequential> > <.../> > </sequential> ></outofdate> > >As regards targets that have no source dependencies, I will need to think >about it. > >The empty sourcefiles example does looks like a bug, either >outofdate should whine, or always run sequential - I am not too sure which! > >Cheers, > >Peter > >On Tuesday 22 April 2003 21:36, Dominique Devienne wrote: > > I wanted to use <outofdate> like this: > > <outofdate> > > <targetfiles> > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${lib.defs.dir}/_defines.h">...</echo> > > </sequential> > > </outofdate> > > > > But was forced to use it like this: > > <outofdate> > > <sourcefiles> > > <pathelement location="${lib.defs.dir}/enter_scope.h" /> > > </sourcefiles> > > <targetfiles> > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${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="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${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 needs >to > > generate files from nothing (out of thin air), one doesn't have a source > > file, but the generation process should nonetheless happen if the target > > 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 |
From: Dominique D. <DDe...@lg...> - 2003-04-23 15:04:32
|
Well, sure you can, but it's just a degenerate case of <outofdate>, much less expressive for that matter! Compare to: > > <outofdate> > > <sourcefiles /> > > <targetfiles> > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${lib.defs.dir}/_defines.h">...</echo> > > </sequential> > > </outofdate> Out-of-date has two requirements: 1) target files exists (the one I'm need here) 2) target files newer than sources (what I don't need here) Missing target files *are* out-of-date, irrelevant of the source files, whether you have some or not. Seems so obvious to me... --DD -----Original Message----- From: Brad Clarke [mailto:bc...@bo...] Sent: Wednesday, April 23, 2003 9:52 AM To: ant...@li... Subject: RE: [Ant-contrib-developers] Little issue with <outofdate> outofdate is a task designed to compare one set of files against another and react when there are conflicts. Your case seems to be that if either of two files don't exist you want to generate both of them. To me it would make a lot more sense as something like this: <if> <not> <and> <available file="${lib.defs.dir}/_undefs.h"/> <available file="${lib.defs.dir}/_defines.h"/> </and> </not> <then> <sequential> <echo file="${lib.defs.dir}/_undefs.h">...</echo> <echo file="${lib.defs.dir}/_defines.h">...</echo> </sequential> </then> </if> At 09:23 AM 4/23/2003, Dominique Devienne wrote: >I thought you might say that, but in this case, the content of files will >never change anymore (for sure), and doing as you say would force the >recompilation of *everything* since these headers are included (indirectly) >by everything. I very often change the common.xml XML entity included for >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' alternatives: >Whining dismisses my use case (which I persist is valid), and always >executing <sequential> simply is wrong, since shouldn't be executed when 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 =...></echo> in the <sequential/>) the target >files need to be changed. > >I would (and have in my build files) do ><outofdate> > <sourcefiles path="build.xml"/> > <targetfiles> > <...> > </targetfiles> > <sequential> > <.../> > </sequential> ></outofdate> > >As regards targets that have no source dependencies, I will need to think >about it. > >The empty sourcefiles example does looks like a bug, either >outofdate should whine, or always run sequential - I am not too sure which! > >Cheers, > >Peter > >On Tuesday 22 April 2003 21:36, Dominique Devienne wrote: > > I wanted to use <outofdate> like this: > > <outofdate> > > <targetfiles> > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${lib.defs.dir}/_defines.h">...</echo> > > </sequential> > > </outofdate> > > > > But was forced to use it like this: > > <outofdate> > > <sourcefiles> > > <pathelement location="${lib.defs.dir}/enter_scope.h" /> > > </sourcefiles> > > <targetfiles> > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${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="${lib.defs.dir}/_undefs.h" /> > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > </targetfiles> > > <sequential> > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > <echo file="${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 needs >to > > generate files from nothing (out of thin air), one doesn't have a source > > file, but the generation process should nonetheless happen if the target > > 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 ------------------------------------------------------- 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 |
From: Brad C. <bc...@bo...> - 2003-04-23 15:24:19
|
> Out-of-date has two requirements: > 1) target files exists (the one I'm need here) This isn't actually a requirement as I use outofdate to determine which target files are missing, but I would think that my "freakish" case should require a <mapper>, as should any case where the target files are not explicitly defined. I personally think that if a target file is missing then it should just be considered out of date, but... > 2) target files newer than sources (what I don't need here) ...in your case there are no sources, so I believe the build should fail at this point. I just can't wrap my head around the mentality of using a task for something it wasn't designed for when there are other more explicit (and therefore self documenting) ways to do the job. The reason outofdate requires sourcefiles and targetfiles is that it's purpose is to compare the two sets. If you don't have two sets of files then the next guy to come along and see your build file could be just as lost as I am trying to figure out why this task is being used at all. Brad At 10:04 AM 4/23/2003, Dominique Devienne wrote: >Well, sure you can, but it's just a degenerate case of <outofdate>, much >less expressive for that matter! Compare to: > > > > <outofdate> > > > <sourcefiles /> > > > <targetfiles> > > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > > </targetfiles> > > > <sequential> > > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > > <echo file="${lib.defs.dir}/_defines.h">...</echo> > > > </sequential> > > > </outofdate> > >Out-of-date has two requirements: >1) target files exists (the one I'm need here) >2) target files newer than sources (what I don't need here) > >Missing target files *are* out-of-date, irrelevant of the source files, >whether you have some or not. Seems so obvious to me... --DD > >-----Original Message----- >From: Brad Clarke [mailto:bc...@bo...] >Sent: Wednesday, April 23, 2003 9:52 AM >To: ant...@li... >Subject: RE: [Ant-contrib-developers] Little issue with <outofdate> > >outofdate is a task designed to compare one set of files against another >and react when there are conflicts. Your case seems to be that if either of >two files don't exist you want to generate both of them. To me it would >make a lot more sense as something like this: > ><if> > <not> > <and> > <available file="${lib.defs.dir}/_undefs.h"/> > <available file="${lib.defs.dir}/_defines.h"/> > </and> > </not> > <then> > <sequential> > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > <echo file="${lib.defs.dir}/_defines.h">...</echo> > </sequential> > </then> ></if> >At 09:23 AM 4/23/2003, Dominique Devienne wrote: > >I thought you might say that, but in this case, the content of files will > >never change anymore (for sure), and doing as you say would force the > >recompilation of *everything* since these headers are included (indirectly) > >by everything. I very often change the common.xml XML entity included for > >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' alternatives: > >Whining dismisses my use case (which I persist is valid), and always > >executing <sequential> simply is wrong, since shouldn't be executed when >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 =...></echo> in the <sequential/>) the target > >files need to be changed. > > > >I would (and have in my build files) do > ><outofdate> > > <sourcefiles path="build.xml"/> > > <targetfiles> > > <...> > > </targetfiles> > > <sequential> > > <.../> > > </sequential> > ></outofdate> > > > >As regards targets that have no source dependencies, I will need to think > >about it. > > > >The empty sourcefiles example does looks like a bug, either > >outofdate should whine, or always run sequential - I am not too sure which! > > > >Cheers, > > > >Peter > > > >On Tuesday 22 April 2003 21:36, Dominique Devienne wrote: > > > I wanted to use <outofdate> like this: > > > <outofdate> > > > <targetfiles> > > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > > </targetfiles> > > > <sequential> > > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > > <echo file="${lib.defs.dir}/_defines.h">...</echo> > > > </sequential> > > > </outofdate> > > > > > > But was forced to use it like this: > > > <outofdate> > > > <sourcefiles> > > > <pathelement location="${lib.defs.dir}/enter_scope.h" /> > > > </sourcefiles> > > > <targetfiles> > > > <pathelement location="${lib.defs.dir}/_undefs.h" /> > > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > > </targetfiles> > > > <sequential> > > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > > <echo file="${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="${lib.defs.dir}/_undefs.h" /> > > > <pathelement location="${lib.defs.dir}/_defines.h" /> > > > </targetfiles> > > > <sequential> > > > <echo file="${lib.defs.dir}/_undefs.h">...</echo> > > > <echo file="${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 needs > >to > > > generate files from nothing (out of thin air), one doesn't have a source > > > file, but the generation process should nonetheless happen if the target > > > 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 > > > >------------------------------------------------------- >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 |
From: peter r. <pet...@co...> - 2003-04-23 16:29:35
|
On Wednesday 23 April 2003 16:22, Brad Clarke wrote: > I personally think that if a target file is missing > then it should just be considered out of date, but... This is the behaviour of outofdate. > If you don't have two sets of files then the next guy to come > along and see your build file could be just as lost as I am trying to > figure out why this task is being used at all. This is correct and the use of <if> <available> is more self explaining. However, outofdate should deal with empty <sourcefiles> and Dominque's suggestion makes sense. Peter. |
From: peter r. <pet...@co...> - 2003-04-23 15:42:02
|
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 |
From: peter r. <pet...@co...> - 2003-04-23 16:20:27
|
On Wednesday 23 April 2003 16:44, peter reilly wrote: > I still think that your generated files depend on the build.xml, or > common.xml file, but I can see your problem. you could try: <outofdate> <sourcefiles path=3D"${basedir}/common.xml"/> <targetfiles> <pathelement location=3D"${lib.defs.dir}/.proxy._undefs.h" /> <pathelement location=3D"${lib.defs.dir}/.proxy._defines.h" /> </targetfiles> <sequential> <echo file=3D"${lib.defs.dir}/.proxy._undefs.h">...</echo> <echo file=3D"${lib.defs.dir}/.proxy._defines.h">...</echo> <if> <filesmatch file1=3D"${lib.defs.dir}/.proxy._undefs.h" file2=3D"${lib.defs.dir}/_undefs.h/> <else> <copy tofile=3D"..." file=3D"..."/> </else> </if> <if> <filesmatch file1=3D"${lib.defs.dir}/.proxy._defines.h" file2=3D"${lib.defs.dir}/_defines.h/> <else> <copy tofile=3D"..." file=3D"..."/> </else> </if> </sequential> </outofdate> A bit verbose, and it looks like line noise ;-) and=20 uses extra files but it means that if the stuff in <echo ...> changes then the generated files get updated. Peter. |