bug-make
[Top][All Lists]
Advanced

[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: Sun, 03 Feb 2013 23:40:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130113 Thunderbird/17.0.2

On 03.02.2013 23:20, Matěj Týč wrote:
>> If that happens how about replacing
>>
>>   $(MAKE) cache-foo
>>
>> by something like
>>
>>   mkdir .lock 2>/dev/null || exit 0 ; \
>>       $(MAKE) cache-foo ; \
>>       ret=$$?; \
>>       rmdir .lock && exit $${ret}
>>
>> The idea is:
>>
>>  - mkdir can only succeed once
>>
>>  - if "$(MAKE) cache-foo" fails
>>
>>     1. the whole should return non-zero
>>
>>     2. .lock is not left laying around
> 
> Thank you,
> but just by looking at it, I think that if .lock exists, 0 is returned
> and while one make job is busy loading the cache, the others act like
> the cache was loaded.
> Writing the makefile and trying it confirms this assumption, so I guess
> that it has to behave like that.

I see, so actually waiting is needed.

Have you tried modifying the call to do that?  I'd bet it's possible :-)


> I am beginning to think that the most elegant (from the user's point of
> view) would be (probably optional) ignore of order-only dependencies if
> the target exists and is more up-to-date than its ordinary dependencies.

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.


> How difficult could be writing a patch that would enable this?

No idea without having a closer look.  To be honest, I am not yet
convinced that this feature would be of real use to other users or that
a new a global switch would be the best way to address this issue, if
really wanted.

Best,



Sebastian




reply via email to

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