Subject: Re: Distinguish between MKfoo and SUPPORT_foo
To: None <thorpej@wasabisystems.com>
From: James Chacon <jchacon@genuity.net>
List: tech-toolchain
Date: 03/20/2002 23:08:13
Sounds good to me. Are you going to add this to the bsd.README file?

(keeping track of MKfoo vs NOfoo vs ... gets hard at times unless you happen
to remember or use it often).

James


>
>So, while building an image for an embedded system, I needed to chop
>out some stuff form libc to shrink it a bit (namely, YP and Hesiod),
>and rip Kerberos support out of some programs I needed on the flash
>image.
>
>Then I came to realize there are really two aspects to this:
>
>	* Providing the YP API, e.g. having the yp_*() functions
>	  present in libc.
>
>	* Using the YP API, e.g. using the yp_*() functions in
>	  getpwnam(3), rpc.bootparamd(8), etc.
>
>The same issue currently exists with Kerberos support.  Right now we
>always build the Kerberos infrastructure (libraries, support programs),
>and use the MKKERBEROS variable to decide if e.g. login(1) and telnet(1)
>should include Kerberos support.
>
>What I did was split these two things apart.  I now have:
>
>	* MKHESIOD, MKKERBEROS, MKSKEY, MKYP -- Controls whether or
>	  not to build the libraries, support programs, etc.
>
>	* SUPPORT_HESIOD, SUPPORT_KERBEROS, SUPPORT_SKEY,
>	  SUPPORT_YP -- Controls whether or not users of these
>	  facilities use them or not.
>
>If a MKfoo that corresponds to a SUPPORT_foo is set to "no", then
>the corresponding SUPPORT_foo is also implicitly set to "no".  All
>of these things default to "yes", which matches the behavior before
>my changes.
>
>Attached is a diff that does this.  Any objections?
>
>-- 
>        -- Jason R. Thorpe <thorpej@wasabisystems.com>
>