From owner-freebsd-current  Thu Feb 23 08:27:51 1995
Return-Path: current-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id IAA05876 for current-outgoing; Thu, 23 Feb 1995 08:27:51 -0800
Received: from mail.netcom.com (root@mail.netcom.com [192.100.81.99]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id IAA05870; Thu, 23 Feb 1995 08:27:50 -0800
From: patl@asimov.lashley.slip.netcom.com
Received: from lashley.slip.netcom.com by mail.netcom.com (8.6.9/Netcom)
	id IAA08662; Thu, 23 Feb 1995 08:26:49 -0800
Received: by lashley.slip.netcom.com (5.x/SMI-SVR4)
	id AA04296; Thu, 23 Feb 1995 08:29:59 -0800
Date: Thu, 23 Feb 1995 08:29:59 -0800
Message-Id: <9502231629.AA04296@lashley.slip.netcom.com>
To: jkh@freefall.cdrom.com, rkw@dataplex.net
Subject: Re: Building World from Read-Only Media
Cc: current@FreeBSD.org, phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com
Reply-To: lashley@netcom.com
X-Sun-Charset: US-ASCII
Sender: current-owner@FreeBSD.org
Precedence: bulk

|>  OK, guys! I have some new mk files that are much "cleaner" for our make world.
|>  
|>  I have identified 4 strategies for the placement of object files. If one of
|>  these will not please you, SPEAK NOW, or hold your peace.
|>  
|>  Assume that we are compiling /home/my/src/prog/cfile.c
|>  
|>  Case 1. Just put the object next to its source
|>       /home/my/src/prog/cfile.o

I would tend to depriciate this on the grounds of future multi-platform
support, or any of the other reasons that anyone might want to do slightly
different builds in the same source tree.

|>  Case 2. Put the objects in a directory
|>       /home/my/src/prog/obj/cfile.o

I'd prefer to see this generalized to: /home/my/src/prog/${OBJ_DIR}/cfile.o
Same reasons.

|>  Case 3. Global object store
|>       /usr/obj/home/my/src/prog/cfile.o

I'd prefer to see this generalized to: ${DESTDIR}/my/src/prog/cfile.o
Same reasons, plus the following scenario:  I'm trying to get it to
work on my off-beat home system; but the only machine I can do the
builds on is under someone else's control, and they won't give me
root access to write into /usr/obj.

|>  Case 4. Local object tree
|>       /home/my/obj/prog/cfile.o

Again, generalize to: /home/my/${OBJ_DIR}/prog/cfile.o
Same reasons.

|>  Right now, the "world" uses links to make case 3 look like case 2.
|>  My inclination is to go to case 4 instead.

I think I'd lean towards the generalized version of case 4 as well.
One of the advantages of having the object tree branch off fairly
early from the source is that it makes it easy for the object to be
on a different partition.  (Disk space issues, multiple builds,
source NFS mounted/object local, source on read-only media...)

|>...
|>  
|>  I am presently finishing up to procedures necessary to allow links in a
|>  source tree to point to directory trees rather than each file. It is easy
|>  unless you want to cd down in the tree and "make" some subtree rather than
|>  making the whole tree.
|>  However, I think I can do it provided you supply a DESTDIR in advance.

Great idea.

|>  Can I write a makefile rule that can export an env variable.
|>  
|>  What I would like to do is
|>  
|>       cd /top/of/tree
|>       make plant-my-root
|>       cd  down/the/tree
|>  
|>       and have DESTDIR=/top/of/tree

The classic way of handling this is to have Makefiles at the first
level include 'TOPDIR=../ and DESTDIR=${TOPDIR}mumble', at the second
level: 'TOPDIR=../../ and DESTDIR=${TOPDIR}mumble/foo', etc.  This
has the advantage of containing a reasonable default, and being easy
to override at make time.




-Pat