Subject: Re: New possibility to move "obj" logic *out* of make(1)
To: Todd Vierling <tv@wasabisystems.com>
From: Christos Zoulas <christos@zoulas.com>
List: tech-toolchain
Date: 10/31/2001 11:06:35
On Oct 31, 10:43am, tv@wasabisystems.com (Todd Vierling) wrote:
-- Subject: Re: New possibility to move "obj" logic *out* of make(1)

| Well, this would require modifications to affected third-party code as
| described by bin/3938.  It also doesn't address the points of being able to
| maintain the detection code within <bsd.obj.mk> so as to simplify
| BSDSRCDIR/BSDOBJDIR, MAKEOBJDIR, and MAKEOBJDIRPREFIX.

I understand.

| How about this?:
| 
| - move objdir handling to <bsd.obj.mk>
| - disable the built-in make(1) logic by default
| - add command line option to *enable* the built-in make(1) objdir handling
| 
| Basically, the idea here is to cause make(1) to have zero innate knowledge
| of objdirs by default, relegating handling to explicit .OBJDIR: rules only.
| The command line option would re-enable the old logic, in the case that a
| user of a new make(1) might want to build a tree, such as an old NetBSD
| tree, expecting classical BSD-make objdir handling.[*]
| 
| [*] With the advent of the "POSIX compliance code" added by sjg, would
|     compatibility with Old trees be possible anyway?  Should this
|     command line option possibly also turn on and "old BSD make"
|     compatibility mode whereby the new POSIX behavior is turned off?

Part of the OBJDIR magic is to implicitly add .CURDIR in the search path.
I supposed it could be done with .PATH statements, but it ends up being
messy very quickly. I don't know, try it out.

christos