Re: problem with updating a static library using make/makefiles

[Kate Ebneter]

On Dec 5, 2003, at 12:37 AM, Thomas Lavergne wrote:

> <problem with archives snipped>

> How is it possible that prerequisites newer than target do not imply the remake of the target??
> If it is possible, then please indicate me what are the possible situations so that I can check everything.

I know this one, because I just encountered a similar problem myself. (In someone else's makefiles. :-))

Here's what they've done (simplified a bit for clarity). Suppose we have the following source tree structure:

foo
|
---------------------------
|            |            |
a            b            c


foo contains a file, foo.mk, the gist of which is

CONFIGURATION = \
liba.mk \
libb.mk \
libc.mk

...along with a rule for CONFIGURATION that basically recurses into each subdirectory (a, b, c) and executes make there.

a, b, and c each contain makefiles lib{a,b,c}.mk, each of which looks like

OBJECTS = \
ax.o \
ay.o \
az.o {etc.}

LIBRARY = foo.a

Now, our rule for what to do with a LIBRARY looks like (somewhat abstracted for clarity)

$(LIBRARY): $(OBJECTS)
$(LIBRARIAN) $(LIBRARIANFLAGS) $(LIBRARY) $?

... that is, just stuff the relevant object files into the library. Note that foo.a just depends on the object files. Here's the (slightly subtle) catch: As soon as I update foo.a from one directory, it becomes NEWER than the modified files in the other directories so it is up-to-date with respect to them and they never get (re-)added to the archive! Some builds will work correctly, while others will not.

The solution is for foo.a to depend on liba.a, libb.a, etc.:

foo.mk:

CONFIGURATION = \
liba.mk \
libb.mk \
libc.mk

LIBRARY = foo.a

SUB-LIBRARIES =
liba.a \
libb.a \
libc.a

... add a rule for making foo.a out of the sub-libraries, e.g.,

$(LIBRARY) : $(SUB-LIBRARIES)
$(LIBRARIAN) $(LIBRARIANFLAGS) $(LIBRARY) $?

lib{a, b, c}.mk:

OBJECTS = \
ax.o \
ay.o \
az.o {etc.}

LIBRARY = liba.a

Now foo.a gets built from liba.a, libb.a, libc.a, etc. (This works because our rule gets translated into something approximately like

foo.a : liba.a libb.a libc.a

in foo.mk, where it will be invoked *after* lib{a,b,c}.mk.)

This doesn't solve all the problems with archives -- for example, if you delete a source file, the corresponding object file will be in the archive until you completely rebuild it -- but it's a big step forward.

Hope that helps,

Kate Ebneter
Build Engineer
Apple Computer, Inc.