Thus spake Jaromir Dolecek ("JD> ") sometime Today...

JD> > MKCRYPTO_IDEA=YES
JD> > MKCRYPTO_RC5=YES
JD> > MKCRYPTO_RSA=YES
JD> > MKCRYPTO_IDEA=YES
JD> > MKCRYPTO_RC5=YES
JD> > MKKERBEROS=YES
JD>
JD> You have duplicate  MKCRYPTO_RC5 and MKCRYPTO_IDEA :)
JD>
JD> IDEA/RC5 shouldn't be used by any pkg directly - the algortihms
JD> are patented, and only available for noncommercial use.
JD>
JD> Just comment it all out - default is no, so it should DTRT.

There are other things in there that one might want when rebuilding
their own world in pieces but which are inappropriate when building a
'build' or 'release' or 'distribution' target.

I might recommend surrounding the lines with

.ifndef __BUILD__
.else
.endif

and then calling build.sh with -V __BUILD__=1

or some such.

[Ostensibly, build.sh should set a variable when running so that one
can set these sorts of things.]

It's painful to *HAVE* to build the cat pages AND the lint libraries
AND... when one really doesn't want to, but if you don't, the mtree
comparison fails in make release or make distribution.

This does not strike me as an optimal situation.

If one is building a build for one's own box, this shouldn't be a problem;
but if one is building for a release/distrib, we need to be able to do
one of:

	- use default values for those "user-tuneable build flags" if
	  doing a build-for-release, or

	- have mtree chunks which depend on the truth of those build flags,
	  and construct a master mtree from those chunks which we then
	  use to compare a built release.

Otherwise, any site with a custom installation or any preferences
outside the norm will never be able to properly build a release or
a distribution.

				--*greywolf;
--
NetBSD: Someday, we won't burn your toast.