>Let's take a silly example - my
>- 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
rather than simply
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
>Then place the dependset task after the one that generates the build
Yes in general I think you are right-- you would place the call to
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 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
>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 specifies "*.dtd"
and there aren't any dtd files,
I wouldn't consider it either way. The problem arises when
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.