From owner-freebsd-current Wed Apr 5 09:47:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA23684 for current-outgoing; Wed, 5 Apr 1995 09:47:39 -0700 Received: from dataplex.net (SHARK.DATAPLEX.NET [199.183.109.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA23678 for ; Wed, 5 Apr 1995 09:47:35 -0700 Received: from [199.183.109.242] by dataplex.net with SMTP (MailShare 1.0b8); Wed, 5 Apr 1995 11:46:40 -0500 X-Sender: wacky@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Apr 1995 11:46:43 -0500 To: Garrett Wollman From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Why do you care WHERE the obj files reside? Cc: current@FreeBSD.org Sender: current-owner@FreeBSD.org Precedence: bulk ><Wackerbarth) said: > >> I don't understand how this is related to WHERE the objects are located. >> In order to DTRT, the objects could be totally inaccessable to YOU as long >> as they were accessable to the "Make". > >Because I want things like `touch obj/foo.o' to still work right. I'm not sure why YOU want to do this. It is certainly not the cannonical form of a directive for a make rule. You must be trying to "trick" make into doing something that it would not routinely do. However, as I have previously said, YOU may add links to your tree. It is just that "make" will not use them. > And >I want things like `cd /usr/src/usr.sbin/mrouted; patch -p < >~/mrouted.patch; make depend && make all && make install' to work >without having to screw with enviroment variables, mount points, >symbolic links, or other detritus. If you wish to alter the sources in YOUR tree, go right ahead. Of course you will not be reading them from the CDROM. As for the "make" portion of that line, I, too, expect it to work. That is DTRT. Since you have described only one tree, I can use the default definition of the TREE_ROOT, namely "/usr". I'll find the sources in /usr/src/xxx and place the objects in /usr/obj/xxxx just as the present version does. The complication occurs when you have multiple trees and add symbolic links to common code. You have to tell me which tree you are in. ---- Richard Wackerbarth rkw@dataplex.net