Date: Thu, 23 Feb 1995 08:29:59 -0800 From: patl@asimov.lashley.slip.netcom.com To: jkh@freefall.cdrom.com, rkw@dataplex.net Cc: current@FreeBSD.org, phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com Subject: Re: Building World from Read-Only Media Message-ID: <9502231629.AA04296@lashley.slip.netcom.com>
next in thread | raw e-mail | index | archive | help
|> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502231629.AA04296>