help-make
[Top][All Lists]
Advanced

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

Re: Library dependency files


From: Todd Showalter
Subject: Re: Library dependency files
Date: Tue, 27 Apr 2010 15:40:02 -0400

On Tue, Apr 27, 2010 at 3:16 PM, Paul Smith <address@hidden> wrote:

>> Depending on *how* we build this file, it will have different
>> dependencies.  The logic is, if anything, backwards; it's the
>> destination file (ie: the .o file) that should have the dependency
>> information attached to it.
>
> I'm not sure what you mean here: certainly it's the target (.o) that has
> the prerequisite information attached to it.  What else would have it?
> It cannot work to have the prerequisites defined for the source file.
> Maybe the document was confusing?

    Unless I misread, the implication was that foo.o depends on foo.c
and foo.P.  For this bit, I was only saying that $(OBJDIR)/foo.o needs
to depend on $(OBJDIR)/foo.P and foo.c, rather than on foo.P and
foo.c.  The case considered in the document is the 1:1 mapping case
where the object file lives next to the source file in the same
directory and shares everything except the suffix.  In builds where
this is not the case, some hoops need to be jumped to make things
work.

> If you are passing different -D options to build .o's, then either (a)
> you'll have to clean out your source tree between builds so you get
> recompiles when the -D options change, or (b) you have different
> destination directories for the .o files (or, sometimes, modify the .o
> filename depending on how it was compiled) when built with -D.
>
> If (a), then just be sure to clean out the .d files at the same time as
> the .o files and you're good.  If (b), then be sure to put the .d files
> in the same location (or use the same naming convention) as the .o files
> and you're good.  I don't see a problem here.

    We're case b, but the problem remains.  I'll try to give a more
concrete example:

    Say we've got an environment variable, $BUILD_NETWORK_SUPPORT, and
it's currently set to 0.  Within the makefile we have

CFLAGS+= -DBUILD_NETWORK_SUPPORT=$(BUILD_NETWORK_SUPPORT)

    Within a C file we have:

#if (BUILD_NETWORK_SUPPORT == 1)
#include "Network.h"
#else
#include "Network.Stub.h"
#endif

    Now say on the command line I do:

make
export BUILD_NETWORK_SUPPORT=1
make

    The second invocation of make will not detect the change, and the
dependencies will be wrong.

                                                                Todd.

-- 
 Todd Showalter, President,
 Electron Jump Games, Inc.




reply via email to

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