Make and libraries

[Spencer W. Thomas]

Our solution to this problem (updating library elements from the .c
files, without keeping all the .o files around) was multifold

1. Fix the library(member) "stat" call in make (it was broken when BSD
went to ASCII archives).  (I also added caching, since it was otherwise
N**2 to update all of a large library - you lose some timestamp accuracy
if you update the library in the middle of the run, but it runs LOTS
faster (we have one library with over 180 elements)).

2. Put in rules of the form
library(member.o):	member.c .h-files
	compile -c compile-options member.c
	touch didwork
for compiling the individual members.  Note that this does NOT add the
new .o file to the library (in that aspect, it lies to make).  The
'touch didwork' lets the following rule work.

3. Put in a rule to add the new .o files to the library
library:	didwork
	ar ru library *.o
	rm *.o
	untouch didwork
untouch sets the date on didwork to an ancient date (but 0 doesn't
work, as make interprets a 0 date as a non-existent file).  This almost
has it, except for one thing:  If one of the compiles fails, make will
update the library (since didwork is newer than the library), then
recompile the .c files that are still out of date, but will not add them
to the library (since it thinks that the library is newer than didwork
-- it doesn't know that didwork has been touched.  With some more
chicanery involving a couple more zero-length files, you can get it to
	a. Add all the .o files lying around to the library.
	b. Compile any .c files that are out of date.
	c. Add the resulting .o files to the library.

It's a work-around, but it does work.  The other thing that makes it all
work is an automatic makefile generator (writing all those rules by hand
is ridiculous).
-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas at utah-cs.ARPA)
	"You don't get to choose how you're going to die.  Or when.
	 You can only decide how you're going to live." Joan Baez