Re: Library dependency files

[Todd Showalter]

On Wed, Apr 28, 2010 at 5:34 PM, Erik Rull <address@hidden> wrote:

>>    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.
>
> Simple solution:
> - write down the current parameter settings that will be changed via
> Makefile parameters into a file (e.g. echo -en "$(CFLAGS)" >
> compile_settings.txt; syntax might be wrong, just to show what I want to
> express)
> - read the file and compare it to the "current" settings string. If
> different do a clean and then a make and sync the file with the most recent
> parameters
>
> You just need a function in your makefile how to create the string and how
> to read the file and compare it and what to do if it has changed.
>
> Should be possible to be solved with pure make.

    Easier solution: rerun makedepend on all files every build, and
eat the half second it costs,  Seriously, I've timed it, and it's
~500ms on our project on a decent machine and getting faster every
time the machines get better  My i860 takes an average of ~110ms
(real) for a nothing-to-do build.  Mind you, the way we've laid our
project out probably helps us on this; every file in the project
depends on the whole header set (which is pretty much inescapable in
console game development), so with the exception of private header
files the whole dependency tree is parsed on the first file and
cached.  Subsequent files just get copies of the same tree.

    Doing a complete dependency sweep every build means there are no
special hacks in the makefile, no chance we missed a corner case or a
variable, and the execution time is nearly equivalent, even on
nothing-to-be-done builds.  Saving some fraction of a half second in
exchange for making the build process more complex doesn't strike me
as a win.

    Now, if your dependencies were taking on the order of tens of
seconds or more to generate, that would be another question entirely.
And if you aren't using environment variables to drive your build
process, the paper we're discussing works fine.  The idea the paper
describes is good, and I don't mean to say it isn't.  My only point
here is that use of environment variables to drive the build breaks
assumptions the paper makes (ie: that make will detect all changes
that require dependency recalculation), and force you to add
additional complexity to the system.

    I don't see this as a fault in make, or in the paper.  It's just a
consequence of the particular way our build is set up.  We've got
multiple platforms and multiple configurations supported in a single
source tree, and we want to be able to access those without having to
run a "configure" step.  Our build supports multiple game consoles and
operating systems, enables or disables features on those platforms
(networking, movie playback, debug printing, storage access
mechanisms, graphics APIs...), and allows variant compilation for
different language and legal regions.  To make it all work without a
"configure" step, we have environment variables that control various
flags.

    We could probably can them all up in config files and add them to
the dependency graph; that would get rid of the "dependency change
sneaks past make" problem, but once again it would add complexity
(more files to maintain, a more complex build process, would need some
way of telling make which file to use...) and buy us nearly nothing in
return over the system we already have.

                                                     Todd.

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