From owner-freebsd-current  Mon Sep  9 12:38:48 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA14560
          for current-outgoing; Mon, 9 Sep 1996 12:38:48 -0700 (PDT)
Received: from meter.eng.uci.edu (root@meter.eng.uci.edu [128.200.85.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA14553
          for <freebsd-current@freebsd.org>; Mon, 9 Sep 1996 12:38:46 -0700 (PDT)
Received: from newport.ece.uci.edu by meter.eng.uci.edu (8.7.4) id MAA09567; Mon, 9 Sep 1996 12:38:43 -0700 (PDT)
Received: from localhost by newport.ece.uci.edu (8.7.4) id MAA13249; Mon, 9 Sep 1996 12:38:41 -0700 (PDT)
Message-Id: <199609091938.MAA13249@newport.ece.uci.edu>
To: Bruce Evans <bde@zeta.org.au>
cc: freebsd-current@freebsd.org
Subject: Re: Object directory changes to make 
In-reply-to: Your message of "Tue, 10 Sep 1996 05:02:22 +1000."
             <199609091902.FAA24911@godzilla.zeta.org.au> 
Date: Mon, 09 Sep 1996 12:38:40 -0700
From: Steven Wallace <swallace@ece.uci.edu>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>First make will search for MAKEOBJDIR.machine, then MAKEOBJDIR,
>>as previously done.  Then if both failed it will search for
>>MAKEOBJDIRPREFIX/`cwd`/machine and then MAKEOBJDIRPREFIX/`cwd`.
>>If all fails the cwd is used.
> 
> I use an environment variable MAKEOBJTREE instead of the hard coded 
> prefix MAKEOBJDIRPREFIX.  Experience showed:
> 
> 1) The environment variable is too inconvenient (as expected).  It
>    will have to be hard-coded for a transitional period until it can
>    be read from an include file (`make' now doesn't read include files
>    until after it decides the object dir.  This behaviour is fundamental
>    because ifdefs etc. to control the reading of include files may depend
>    on the object dir).
> 
> 2) There should be no slash between MAKEOBJDIRPREFIX and `cwd`.  `cwd`
>    begins with a slash (except possibly when it is actually $PWD), and
>    the extra slash is unnecessary if MAKEOBJDIRPRFIX is nonempty and a
>    bug otherwise.
I put that there for easy reading...not in code.

> 
> 3) .TARGETOBJDIR is bogus and unnecessary.  bsd.obj.mk can easily
>    concatenate ${MAKEOBJDIRPREFIX} and ${.CURDIR} itself provided it
>    knows ${MAKEOBJDIR}.  It needs to do this to get an unambiguous
>    path.  Chdir checks in `make' don't work because the name of the
>    path must not depend on the existence of the path.
>    
I agree it should be done away with.  Do we want to do that now?

>    This seems to be quite broken in your version.  .TARGETOBJDIR is set
>    ${path}.${MACHINE}, where ${path} is ${MAKEOBJDIR} if that is set in
>    the environment, else "obj".  This seems to break both the new and
>    the old tree names.
> 
Fixed

> 4) MAKEOBJDIRPREFIX is a better name than MAKEOBJTREE.
> 
> 5) .${MACHINE} causes similar problems to ${MAKEOBJTREE}/.  It should
>    be a general suffix, named ${MAKEOBJDIRSUFFIX} and any necessary
>    punctuation (usually "."; perhaps "/") should be part of the suffix.
>    It should not be decided inside `make'.
Huh?

> 
> 6) `make's builtin search path should go away.  The effect of its
>    builtin "obj" path can easily be obtained using the new
>    MAKEOBJDIRPREFIX.  It probably isn't necessary for the prefix to
>    actually be a search path, and the ambiguity for a path usually gets
>    in the way.  Overriding the prefix is probably good enough doing
>    local changes.  MAKEOBJDIR didn't work before, so it won't be missed.
> 

It would be nice if the object directory could be set by the makefile
or an include file, but until then the search path is needed.
With MAKEOBJDIRPREFIX, MAKEOBJDIR is not needed to build the src tree.
However, it is still needed for compatability for other trees users
have built using previous FreeBSD releases.

I am confused.  What would you like to do?
I would like to put my changes into place until major changes
to allow the makefile/include to determine the object directory.

Steven