Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Aug 1999 16:01:17 +0200
From:      Neil Blakey-Milner <nbm@mithrandr.moria.org>
To:        Nik Clayton <nik@freebsd.org>
Cc:        doc@FreeBSD.org
Subject:   Re: Some proposed changes in expectation of obj'able doc makes
Message-ID:  <19990823160116.A96603@rucus.ru.ac.za>
In-Reply-To: <19990823140332.C2121@catkin.nothing-going-on.org>; from Nik Clayton on Mon, Aug 23, 1999 at 02:03:32PM %2B0100
References:  <19990823115900.A6290@rucus.ru.ac.za> <19990823140332.C2121@catkin.nothing-going-on.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon 1999-08-23 (14:03), Nik Clayton wrote:
> I'm sure this is a good idea.  At least, it looks like a good idea, and
> it looks similar to the mechanism used in the src/ Makefiles, and I assume
> it's a good idea there as well.
> 
> But what does it actually do?  Would you (or anyone else on the list) be 
> able to write up a description of what the benefits are, and how they
> work?  This can then be added to the FDP primer, so that newcomers to
> the project have something they can read through which explains things
> like this?

I'll sgml-ify it later, but here's a synopsis:

When you're using "make" to create a project, it is possible to have
the actual output created by the make process to go into a separate
parallel directory tree, so that you don't mess up or otherwise touch
the original tree.

The advantage in this is that the tree can be mounted read-only, or be
owned by another user, exported RO over NFS, be on a CD, or something
like that, and still use it to generate the expected bits.

It also makes it much harder to by mistake delete the originals by
mistake by overwriting them or deleting it whilst aiming at the
generated material.

It also makes it easier to figure what all you are generating, and
whether you're deleting all of it, since anything left behind in the
obj directory after a make clean would have ended up in your original
directory otherwise.

It does this by changing your working directory to .OBJDIR, if it
exists, and which is worked out by adding the current directory to
MAKEOBJDIRPREFIX, which defaults to /usr/obj.  Thus, /usr/doc's .OBJDIR
is /usr/obj/usr/doc by default.  .CURDIR is the current directory.

Make makes sure that the .ALLSRC and .TARGET are converted as
necessarily.  Using the following example:

book.html: book.sgml

.TARGET is book.html, and .ALLSRC is book.sgml usually, but in an obj
build, .TARGET becomes ${.OBJDIR}/book.html and .ALLSRC becomes
${.CURDIR}/book.sgml.

For /usr/doc/foo, .TARGET is /usr/obj/usr/doc/foo/book.html and .ALLSRC
is /usr/doc/foo/book.sgml.

The problem in generating obj'able build processes is remember what
directory you are in, and how to get to files, because you're changed into
the .OBJDIR directory.

In my example, DOC_PREFIX=../../.. doesn't help, since you can't use it
to find the actual doc prefix from .OBJDIR, since its ../../.. usually
points somewhere other than you expect.  This is especially so if you're
doing "jade -d ${DOC_PREFIX}" or whatever, since it's working directory
is actually .OBJDIR, and you don't want a relative path.

Hope that helps,

Neil
-- 
Neil Blakey-Milner
nbm@rucus.ru.ac.za


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990823160116.A96603>