Subject: Re: Toolchain Update (27-Nov-2001)
To: James Chacon <jchacon@genuity.net>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-toolchain
Date: 11/27/2001 12:50:49
On Tue, 27 Nov 2001, James Chacon wrote:

: > - Overhaul src/distrib with common build components and proper recursion.
: >   In particular, I've factored out the identical yet duplicated crunch
: >   and fs build logic.
:
: I assume you mean the N makefiles all containing essentially the same rules
: for doing a crunch build?

Precisely.

: > - Change MKfoo=no back to NOfoo= in various Makefiles.  The behavior
: >   desired here is to override any user setting, which is precisely what
: >   NOfoo does.  (This manifests as a problem when someone sets MKMAN=yes or
: >   MKPIC=yes in mk.conf, which should be a perfectly legal action.)
:
: Back to? I know the idea of MKSHARE=no has been around for some time so some
: actual discussion before possibly breaking lots of people's mk.conf's should
: probably happen here first..

This won't affect anyone's mk.conf file.  The issue is that, for instance,
setting the following in mk.conf:

MKPIC=yes

will cause all libraries in the system (even those meant to build as static
only, within the build tree) to build as a _pic.a library.  Coupled with
MKLINKLIB=no (used to indicate that libraries are for building, but not
installing), you end up with a situation where the static .a doesn't even
exist, and thus the in-tree -L.../obj -lfoo breaks.

What the Makefiles in question want to do is simply force off particular
things that are irrelevant to that subdirectory's build, such as PIC, MAN,
LINT, etc., regardless of whether the MKfoo default is yes or no.  The
proper way to do this should be using the NOfoo variables in each Makefile,
which forces MKfoo=no, even if the mk.conf says MKfoo=yes.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/