Re: [SUBMIT] New task, a task to manage arbitrary dependencies between files

[Craeg K. Strong]

Let's take a silly example - my <style> (using redirect extensions or
something) generates two .html files - the name of one of them will be
passed in as a parameter, something like
<style in="source.xml" 
      out="output1.html"
      style="style-with-redirect.xsl">
 <param name="other-file"
        value="${a-property-only-known-at-build-time}" />
</style>

<snip/>
- maybe output1.html contains a
link to the second file?  If any target file is out of date with
respect to a given source, chances are high that all of them are IMHO.
I liked your example-- point taken.  I will modify the code and docs to 
delete ALL targetfiles
if ANY are out of date.

But I see your point of using a fileset for target files as well,
there are situations where you don't know all the names of the target
files or it would be cumbersome to list them.
Maybe we'd need a targetfileset and a targetfilelist or similar, where
a missing file from the targetfilelist would be treated the same way
as an out-of-date target file?
I see your point here as well.  If someone has gone to all the trouble 
to explicitly name target files as in

<targetfiles dir="mumble" includes="foo.html,bar.html,baz.html"/>
rather than simply
<targetfiles dir="mumble" includes="*.html"/>
Then if one of them does not exist, ALL should be removed in the 
interest of correctness.  I will try
to make a special note of this intricacy somehow in the docs...

A real issue is what to do when one or more SOURCES (not targets)
doesn't exist?  In the example above, that would mean that a
buildfile does not exist.  This is not so preposterous when you
realize that I might be generating my buildfile using XSLT or
whatnot.
Then place the dependset task after the one that generates the build
file?
Yes in general I think you are right-- you would place the call to 
<dependset> in logical order
-after- the rule that generates the buildfile or common XSLT include or 
etc...  but see below.

Other times you might want this situation to be interpreted as if
the target files are NOT out of date.  For example, you might have a
boilerplate <dependset> rule that includes "*.dtd".  But one of your
projects does not yet happen to have any DTD files.  Setting
ignore=true means that this will not result in any target files
being removed.
Searching for sources that have an out-of-date target instead of
targets that are out of date would eliminate this problem, you
wouldn't even consider the *.dtd part.
I don't understand your argument here.  If <srcfiles> specifies "*.dtd" 
and there aren't any dtd files,
I wouldn't consider it either way.  The problem arises when <srcfiles> 
specifies an _explicit_
file like "foo.dtd" but "foo.dtd" does not exist.  (I should have used 
that for my earlier example...)

I still think that you may want to give the buildfile writer a choice in 
how to handle this situation.
n'est-ce pas?

--Craeg