--- Diane Holt <[EMAIL PROTECTED]> wrote: > --- Scott Ellsworth <[EMAIL PROTECTED]> wrote: > > Turns out that <dependset> was what I was missing. > [snip] > > The only problem I am missing now is how to know > > when to build if dependset deletes my files. If > > I run the above, it will certainly > > eradicate everything in the directory if they are > > out of date, but unless I know that something got > > deleted, I will not know that I should > > regenerate the files.
> Do you actually want everything in the directory > deleted, if anything's out-of-date (ie., if any one > thing is out-of-date, does that actually > require everything get rebuilt)? If not, then > <dependset> probably isn't the best way to go. On > the other hand, if yes, then whatever target > currently builds this stuff should just depend on a > target that has the <dependset>, so it'll go do that > first, then, when it comes back to the > original target, the task(s) in it will build > whatever would normally get > built when none of the target-files are there. I had to go back and reread this thread a few days later when I realized I had a similar problem. In my case, I do have a situation where "if any one thing is out-of-date, everything must get rebuilt". My solution so far has been to use dependset to nuke everything (if any one thing is out-of-date) and then use available to check for the existence of a single file. This isn't quite as "safe" as checking all the files but it works. It would be seriously cool to have uptodate support a targetfileset in much the same way dependset does (i.e. work like dependset but set a property rather than delete the files). The build file would also probably communicate the intent of my logic better as well. Rick __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
