[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature request - order only deps

From: Sebastian Pipping
Subject: Re: feature request - order only deps
Date: Mon, 04 Feb 2013 01:09:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2

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:


   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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]