On 4.2.2013 01:09, Sebastian Pipping wrote: > 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 >>> >>> ... >> ... >> >> 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.
Thank you for your reply,and yes, that's it indeed. > > I'm starting to see why you want support for that. Thank you, this sounds good. >> 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: The only relation is that the fact that I wouldn't need a server process neither cache if 'n in' -> 'n out' filter programs were supported like I explain in the comment below. > out%: in% > cp $< $@ > > Here, cp would be the filter. Are you referring to something else? The problem is that if I have like 50 'in' files and I want 50 'out' files, the 'cp' program would be launched 50 times, whereas the "filter" I have in mind is able to consume like 50 files and output 50 files as a result at once. I would say that this could be formulated as "rule that has a dynamic number of targets depending on the number of dependencies (inputs)". > Best, > > > > Sebastian > Best wishes, Matej _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
