Subject: Re: New possibility to move "obj" logic *out* of make(1)
To: Todd Vierling <email@example.com>
From: Christos Zoulas <firstname.lastname@example.org>
Date: 10/31/2001 11:06:35
On Oct 31, 10:43am, email@example.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.
| 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.