cc design flaw
Jeffrey E. F. Friedl
jeff at unh.UUCP
Mon Nov 14 14:59:26 AEST 1988
In article <4700028 at m.cs.uiuc.edu>, wsmith at 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
More information about the Comp.lang.c
mailing list