[Top][All Lists]
[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:00:14 -0400 |
On Tue, Apr 27, 2010 at 1:24 PM, Paul Smith <address@hidden> wrote:
> You might consider reworking your dependency generation based on the
> "Advanced Auto-dependency" article on my website (below).
>
> That might help (it won't change the amount of time make spends
> reading .d files of course).
This method is broken for our case. The scheme you describe
assumes a 1:1 mapping between source files and target files, which
isn't the case in our system.
Consider a hypothetical source file:
#if defined ARCH_WII
#include "Wii/foo.h"
#elseif defined ARCH_PS3
#include "PS3/foo.h"
#elseif defined ARCH_DS
...
#endif
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. Even that isn't enough in our system,
since some of the build metadata lives entirely outside of make's ken;
make will not detect inter-run modifications to environment variables
that can affect dependencies, for instance.
Now, our build system feeds the makefile a list of source/target
pairs, so we could extend your method to place dependencies next to
the appropriate object files; this solves the mapping problem and has
the added benefit that "make clean" can trivially clean out the
dependencies (we build our objects into a separate tree, so "make
clean" is "@rm -rf $(OBJDIR)").
It remains broken, however, in the "cc -D$(FOO)" case and similar,
if an environment variable is used to drive preprocessing in a way
that could affect the dependency graph. In our case, when building,
we hand the compiler -I$(ARCH), where $ARCH is an environment variable
containing the architecture to build. There is no way for make to
know $ARCH has changed between runs unless we explicitly cache it.
In our case, the simple solution was to have a dependency
generation sweep that we run on every build and which hits every
source file. On a relatively modern machine it takes on the order of
a half second.
Todd.
--
Todd Showalter, President,
Electron Jump Games, Inc.
- Library dependency files, Hambridge, Philip J (ODP), 2010/04/26
- Re: Library dependency files, Philip Guenther, 2010/04/26
- Re: Library dependency files, Mike Shal, 2010/04/26
- Re: Library dependency files, Todd Showalter, 2010/04/27
- Re: Library dependency files, Mike Shal, 2010/04/27
- Re: Library dependency files, Todd Showalter, 2010/04/27
- Re: Library dependency files, Paul Smith, 2010/04/27
- Re: Library dependency files,
Todd Showalter <=
- Re: Library dependency files, Paul Smith, 2010/04/27
- Re: Library dependency files, Todd Showalter, 2010/04/27
- Re: Library dependency files, Erik Rull, 2010/04/28
- Re: Library dependency files, Todd Showalter, 2010/04/28
- Re: Library dependency files, Erik Rull, 2010/04/29
- Re: Library dependency files, Todd Showalter, 2010/04/29
- Re: Library dependency files, Erik Rull, 2010/04/30
- Re: Library dependency files, Todd Showalter, 2010/04/30
RE: Library dependency files, Hambridge, Philip J (ODP), 2010/04/27