Re: feature request - order only deps

[Matěj Týč]

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