olson@fortune.UUCP (Dave Olson) (07/29/85)
The problem with suppressing the built-in rule that augmented make uses in dealing with libraries becomes apparrent if there is an error in compiling one of the files. In this case, NONE of the files have been added to the library, and when you fix the error, and start make, ALL those files will once again be compiled. This is especially irritating when the error occurs in the 15th of 16 files! I wrestled with this problem for quite a while, and decided that it is best to go with the built-in rule, or some slight variation thereon. There are many ways to try and solve the above problem, but none of the ones I was able to find were as RELIABLE as the built-in rule, although most of them were somewhat faster... (as you pointed out). The bottom line seems to be that if you are actually doing development, you are going to be happier with the built-in rule, when dealing with libraries. (If you aren't doing development, but are just writing a makefile for some existing code, you MIGHT get away with it, but the next person to work on the code is likely to get burned, especially if they don't thoroughly understand make!) Dave Olson, Fortune Systems
fnf@unisoft.UUCP (07/30/85)
In article <5404@fortune.UUCP> olson@fortune.UUCP (Dave olson) writes: > >There are many ways to try and solve the above problem, but none of >the ones I was able to find were as RELIABLE as the built-in rule, >although most of them were somewhat faster... (as you pointed out). ^^^^^^^^ I agree, if you expect to be making changes that will force recompilation of the entire library, and the recompilation time is significant, then the built in rule is best. However, on our vax 750 the difference in time for rebuilding libc.a (in a 68000 cross environment) went from over 12 hours, with the built in rule, to under an hour with the method I posted previously. This is more than just *somewhat* faster! =========================================================================== Fred Fish UniSoft Systems Inc, 739 Allston Way, Berkeley, CA 94710 USA {ucbvax,decvax}!unisoft!fnf (415) 644 1230 TWX 11 910 366-2145 ===========================================================================
thomas@utah-gr.UUCP (Spencer W. Thomas) (07/31/85)
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@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