Subject: make and archive timestamps?
To: Todd Vierling <tv@netbsd.org>
From: None <kpneal@pobox.com>
List: tech-toolchain
Date: 01/17/2002 22:54:32
On Wed, Jan 16, 2002 at 05:36:16AM +0200, Todd Vierling wrote:
>
> Modified Files:
> 	basesrc/usr.bin/make: config.h
> 
> Log Message:
> Don't look at archive timestamps if MAKE_BOOTSTRAP is set.  (I'm not
> entirely sure that this is useful *at all* these days, since it's been
> turned off for ELF since ELF was brought in....)

What's it good for?

I can see where it might be handy to check the update time on a
member of an archive IFF specific members are part of the dependency
graph. What I totally don't understand is why update times in the
archive are useful at all if the dependency is for the entire archive.

It totally sucks to have archive libraries get rebuilt every time
because make doesn't understand the specific archive library format.
Think cross-compiling, targeting an S/390 or HP-UX or ....


Also, the man page documents these variables:

             .ARCHIVE  The name of the archive file.

             .MEMBER   The name of the archive member.

How are they supposed to be used? I'm curious to see an example of
these in action, working. 


Here's a test makefile I tried: (it has older test leftovers also)

tome% cat test2.mk
one: two
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

two: three
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

three: /usr/lib/libc.a[whatever]
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

putenv:
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

/usr/lib/libc.a[whatever]: four
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

four:
        @echo "${.TARGET} -- ${.OODATE}, ${.ALLSRC}"

tome% make -f test2.mk
three -- , 
two -- three, three
one -- two, two
tome% nm /usr/lib/libc.a | grep whatever
tome% 

I'm not really sure how that was supposed to work. 
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/
           On the community of supercomputer fans:
"But what we lack in size we make up for in eccentricity." 
  from Steve Gombosi, comp.sys.super, 31 Jul 2000 11:22:43 -0600