On 04.02.2013 00:13, Matěj Týč wrote:
> On Ne, 2013-02-03 at 23:40 +0100, Sebastian Pipping wrote:
>> To my understanding, it would have to be optional and off by default to
>> not break other cases that are currently supported. Think of something like
>>
>> tmp:
>> mkdir tmp
>>
>> tmp/foo.pdf: foo.tex | tmp
>> pdflatex -output-directory tmp $<
>>
>> In this scenario, the tmp directory needs to be created if missing.
>
> Actually this would not be a problem, I would need to ignore the 'tmp'
> target iff 'tmp/foo.pdf' existed and was more up-to-date than 'foo.tex'.
> So in cases like that the behavior even wouldn't change at all.
> I think that the problem could arise in cases like this:
>
> Dirs: dir1 dir2
>
> dir%:
> mkdir $@
>
> dir2/foo: dir1/bar
> touch $@
>
> dir1/bar: | Dirs
> touch $@
>
> .PHONY: Dirs
>
> If you make 'dir1/bar', then remove 'dir2' and decide to make
> 'dir2/foo', you appreciate that 'dir2' is remade because 'dirs' is an
> order-only dep of 'bar' and it is remade as soon as make realizes that
> 'dirs' is not complete because 'dir2' is missing.
> So although this can be considered as the Makefile bug, cases like this
> can exist, so the proposed change would break this behavior (I propose
> that the 'Dirs' order-only dep is ignored because dir1/bar is all right
> and dir2/foo says that it depends only on dir1/bar)
If I am not mistaken, you are saying that:
If
1. an order-only dependency is missing and
2. the target is not re-built (i.e. neither missing or older than
"normal" prerequisites
the order-only dependency should not be built.
I'm starting to see why you want support for that.
> I think that this is a nice idea, since 'make' doesn't play well with
> "filters" that can process batches of files at once, the server process
> is a good way to reduce overhead of processing those files one by one
> and you may end up needing a cache quite soon :-)
>
> Actually I might be wrong, but I think that if I have a program 'filter'
> capable of processing in01 in02 in03 ... files to out01 out02 out03 ...
> etc., it is not possible to tell this to 'make', so if out05 and out07
> are needed at some point, 'make' would call 'filter in05 in07 --some
> --flags'. Is that right? Because if this was somehow possible, I would
> not need that process at all.
I do not see the relation to the rest of this thread yet, but what you
describe sounds like classic pattern rules:
out%: in%
cp $< $@
Here, cp would be the filter. Are you referring to something else?
Best,
Sebastian
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
