mj@elmgate.UUCP (Mark A. Johnson) (08/06/87)
I am going out of my mind trying to get Sun 3.4 make(1) to handle long filenames properly with ar. The manual claims it can handle them, but my Makefiles keep dying. The example in the User's Guide (p. 30) is terrible. I would like to have the .o files in a library depend DIRECTLY on the .c files, so that we don't have to keep all of the .o files lying around - it's a ridiculous waste of space. 'mkdir tmp; cp lib.a tmp ; cd tmp; ar xov lib.a; make' is a lousy solution because it's slow and inelegant, it leaves a lot of shrapnel lying around if the make crashes, and it makes practically no use of make's new 'understanding' of ar's namelength 'feature'. I have eliminated the .c.a rule from default.mk because it goes through the out-of-date list performing cc -c, ranlib, and ar ONE FILE AT A TIME. This is an unacceptable waste of time. It should update all of the out-of-date .o files first (not recompiling everything, just those who are out-of-date with respect to their sources) with cc -g, THEN ar and ranlib. I'm not using lorder and tsort because the manual warns that these programs barf on long filenames, too, and I have enough trouble with ar as it is. The other change to default.mk is that the .y.c rule has been changed to fix a stupid bug in yacc. Has this YYSTYPE bug been fixed by 3.4 (or previous)? If so, I'd like to take it out. When I use the makefile (at the top of p. 30 in the Sun 3.4 Make User's Guide) with the default.mk shipped by Sun, make recompiles all of the objects TWICE - once like this cc -flag -flag2 -etc -c file.c and then immediately afterwards like this cc -flag -flag2 -etc -c -o file.o file.c I have no idea what is going on here. As you can see in the Makefile below, I have written a pattern matching rule that builds the .o's (which now blows up because of ar) and I have thrown the .c.a rule away entirely. Please note that this Makefile does EXACTLY what I want it to IF there are no names > 15 characters. Since I have to rewrite 320 Makefiles in the next week, I don't have the time or motivation to shorten all the long filenames in our product. I'd like to know if there's a way around this problem that doesn't require (1) checking everything out of the lib (2) recompiling everything (3) keeping all the .o's lying around (4) waiting for make to run a complete cc-ar-ranlib on every .o file once at a time, rather than cc'ing all the .c's and doing a SINGLE ar-ranlib. I hope I'm just misunderstanding how the make(1) works. advTHANKSance Here's the Makefile: --snip------snip------snip------snip------snip------snip------snip------snip--- CSRCS= a.c why_not_just_fix_ar_instead_of_hacking_make.c COBJS= $(CSRCS:.c=.o) LIB=xyz.a OBJS=$(COBJS) $(LIB): $(LIB)($(OBJS)) ar rv $@ $? ranlib $@ rm -f $? $(LIB)(%.o): %.c $(COMPILE.c) $(OUTPUT_OPTION) $< ------------------------------------------------------------------------------- Mark A Johnson - Eastman Kodak Co. - Dept 646 - KEEPS - Rochester, NY 14650 The opinions expressed above are not necessarily those of Eastman Kodak Company and are entirely my responsibility. UUCP ...rutgers!rochester!kodak!elmgate!mj
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/07/87)
In article <701@elmgate.UUCP> mj@elmgate.UUCP (Mark A. Johnson) writes: > Please note that this Makefile does EXACTLY what I want > it to IF there are no names > 15 characters. ... It is quite possible that your "ar" archive format simply does not support longer names for its members. Many don't, even on systems that permit long directory entries.