Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!rutgers!apple!voder!pyramid!decwrl!megatest!djones
From: djones@megatest.UUCP (Dave Jones)
Newsgroups: comp.lang.c
Subject: Re: cc design flaw
Message-ID: <995@goofy.megatest.UUCP>
Date: 10 Nov 88 05:11:08 GMT
References: <4700028@m.cs.uiuc.edu)
Organization: Megatest Corporation, San Jose, Ca
Lines: 27

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.