help-make
[Top][All Lists]
Advanced

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

Re: Target dependent on input maybe rebuilt by recursive make


From: Britton Kerin
Subject: Re: Target dependent on input maybe rebuilt by recursive make
Date: Tue, 27 Jan 2015 15:22:10 -0900

On Tue, Jan 27, 2015 at 1:55 PM, Jonathan Lennox <address@hidden> wrote:
>
> On Jan 27, 2015, at 5:23 PM, Britton Kerin <address@hidden> wrote:
>
>> On Tue, Jan 27, 2015 at 12:35 PM, Jonathan Lennox <address@hidden> wrote:
>>> Hi —
>>>
>>> I’m trying to structure a Makefile for a situation where a target depends 
>>> on inputs that are in a subdirectory, which can be rebuilt by recursive 
>>> make.
>>>
>>> The specific case is a top-level Makefile which builds a binary, which 
>>> links with static libraries built in a subdirectory.  The top-level 
>>> Makefile doesn’t have visibility into the inputs to the libraries, so it 
>>> needs to invoke the recursive make always.
>>>
>>> The problem I’m having is that Make’s decision as to whether or not to 
>>> rebuild the binary seems to depend on whether the files are old *before* 
>>> the subdirectory make is invoked, not afterwards.  Thus, if an input to a 
>>> library changes, I have to invoke make
>>
>> This is as expected.  Make has no way of knowing what the recursive make 
>> does,
>> as the targets it build aren't knows to the top-level instance.  
>> build-bin-libs
>> is .PHONY afterall (even explicitly declared as such in your Makefile).
>
> I don’t want it to know what the recursive make does; I just want some way 
> for it to check whether the .a files are new, and thus bin needs to be 
> rebuilt, *after* invoking the recursive make.
>
>> Recursive make is bad, basically because by definition it
>> necessarily breaks the dependency graph artificially into pieces.
>> See http://aegis.sourceforge.net/auug97.pdf for details.
>
> I’m familiar with “recursive make considered harmful”, but unfortunately the 
> bin and lib are separate projects.  The individual projects are organized 
> non-recursively.

But you do need to rebuild bin when the lib sources change, right?

>> The easiest
>> solution is probably the build-too-much strategy from the top level: arrange
>> for build-bin-libs to always be invoked from the top level, and ensure that
>> it's an inexpensive mostly-no-op a level down if the libs are up-to-date.
>> So, lose the order-only prerequisite, and have bin depend on build-bin-libs
>> instead, so its clear that they are always rebuilt.  Alternately you could
>> use a stamp target in the top-level dir that depends on the sources (NOT
>> the targets) in the subdir, with a recipe that invokes the recursive make
>> to rebuild them then touches the stamp.
>
> If I make bin depend on the phony build-bin-libs target, bin is rebuilt every 
> time I invoke ‘make’, even if nothing has changed.  Unless I’m 
> misunderstanding your suggestion?
>
> build-bin-libs is certainly a lightweight no-op if there’s nothing to do, 
> that’s easy.  But relinking bin can be expensive.

In that case, the always-rebuild strategy won't work (well enough), and bin
needs to depend on the sources in the subdir.  Explicitly.  Then both the
subdir rebuild and the top level relink need to happen if they change.  Your
problem is you're expecting Make to fix your DAG for you after the rule with
the recipe with the recursive invocation fires.  It doesn't.  It can't.  See
https://www.gnu.org/software/make/manual/html_node/Reading-Makefiles.html#Reading-Makefiles

Britton



reply via email to

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