wsmith@m.cs.uiuc.edu (11/09/88)
The cc compiler in Berkeley unixes leaves .o files in the current directory even when the source file is in different directory. cc -c File/afile.c will leave the .o file at ./afile.o This makes it awkward to build a default .c.o rule for make that will behave correctly when I have several versions of the same files in different sub- directories. Encore's Multimax make solves this problem, but since it is an extension to make, the make files will not port to other machines. Very annoying to say the least. Bill Smith uiucdcs!wsmith wsmith@cs.uiuc.edu
djones@megatest.UUCP (Dave Jones) (11/10/88)
From article <4700028@m.cs.uiuc.edu), by wsmith@m.cs.uiuc.edu: ) ) The cc compiler in Berkeley unixes leaves .o files in the current ) directory even when the source file is in different directory. ) ) cc -c File/afile.c ) ) will leave the .o file at ./afile.o ) ) This makes it awkward to build a default .c.o rule for make that will behave ) correctly when I have several versions of the same files in different sub- ) directories. Encore's Multimax make solves this problem, but since it is ) an extension to make, the make files will not port to other machines. ) ) Very annoying to say the least. ) The "feature" is there so that you can compile sources from a directory which is write-protected into one which is not. Seems to me that it's "make", not "cc" that is doing most of the annoying. Use something else. There's "cake", available from the archives, which does a pretty good job. Or you can rig something up using nawk (new awk). That works well also. You can get sources to both of these programs, so portability is [in theory] not a problem.
bengsig@orcenl.uucp (Bjorn Engsig) (11/11/88)
In article <4700028@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes about the Berkeley cc: > > > cc -c File/afile.c > > will leave the .o file at ./afile.o > Yes, this is the case for ALL cc's, and it should NOT be changed since lotsalotsalotsa makefiles would break then. -- Bjorn Engsig, ORACLE Europe \ / "Hofstaedter's Law: It always takes ..!uunet!mcvax!orcenl!bengsig X longer than you expect, even if you phone: +31 21 59 56 411 / \ take into account Hofstaedter's Law"
jeff@unh.UUCP (Jeffrey E. F. Friedl) (11/14/88)
In article <4700028@m.cs.uiuc.edu>, wsmith@m.cs.uiuc.edu writes: > > The cc compiler in Berkeley unixes leaves .o files in the current > directory even when the source file is in different directory. > > cc -c File/afile.c > > will leave the .o file at ./afile.o > > This makes it awkward to build a default .c.o rule for make that will behave > correctly when I have several versions of the same files in different sub- > directories. Encore's Multimax make solves this problem, but since it is > an extension to make, the make files will not port to other machines. I have no problems with this (if I understand the problem -- maybe not) by using the rule: .c.o: ; $(CC) $(CFLAGS) -c -o $@ $*.c As an example: +--------------------------------------------- | Script started on Sun Nov 13 23:39:05 1988 | % cat makefile | .c.o: ; $(CC) $(CFLAGS) -c -o $@ $*.c | | D=foo | COBJS=$D/this.o $D/that.o $D/theother.o | | target: $(COBJS) | @echo final link here | % make | /bin/cc -c -o foo/this.o foo/this.c | /bin/cc -c -o foo/that.o foo/that.c | /bin/cc -c -o foo/theother.o foo/theother.c | final link here | % | script done on Sun Nov 13 23:39:49 1988 +-------------------------------------------- I've found that this works under BSD4.3 and SunOS 4.0, but not under ULTRIX V2.3 or NCUBE's AXIS (pseudo-UNIX). The latter don't allow the -o file to be certain things (such as ".o", ".c" and/or ".a"). The former require the source and target to differ, and perhaps that the target not end with ".c". Seems poeple do it different ways (I like the BSD/Sun way -- the "cc" for a cross compiler I wrote does it that way). Maybe you're working with one of "the others". If not, try the above. *jeff* ------------------------------------------------------------------------------- Jeffrey Eric Francis Friedl, Box 2146 Babcock House, Durham New Hampshire 03824 ..!{uunet,decvax}!unh!jeff (603)862-3786 USA