On Thu, 24 Mar 2005, Quentin Garnier wrote:

> Until a few weeks ago when I was notified of an issue building
> net/netbsd-tap, I had never realised we were invoking builds with
> MAKECONF=/dev/null in the environment.
>
> The idea behind this is to prevent /etc/mk.conf from tampering with a
> compilation supposedly completely under the control of pkgsrc.  I agree
> it is something we're very likely to want.

Not only is it wanted, it's a pretty solid requirement.  To wit:

> However, the fix is not right, as it brings issue in the case of a
> completely legitimate (and very system-dependent!) build of a LKM.

> Then we have this package, which is a LKM specific to OtherBSD.  As it's
> a very system-dependent package, it will use OtherBSD's make(1), and
> OtherBSD's make(1) configuration, possibly /etc/mk.conf.
>
> In that example, passing MAKECONF=/dev/null is _very_ wrong, as pkgsrc's
> settings and OtherBSD's settings simply cannot clash, the make programs
> are not the same and pull in different files.

No.  If you need configuration bits to find the kernel source or somesuch,
that should be passed in to the sub-make manually as part of MAKE_ENV, so
that the environment of that build is well controlled.

If it's a LKM for OtherBSD, then the package's Makefile should take *only*
the bits it needs to build a LKM for OtherBSD and pass them in directly.
The process of extracting that data and handing it over to an "isolated"
make(1) invocation should be a trivial piece of glue.

See, the flip side of allowing any arbitrary mk.conf to a build is that you
*will* get (even in the case of a LKM) users setting options that cause the
pkgsrc build to fail in unexpected ways.  The environment used to do the
sub-make invocation must be as isolated as possible from such variables.

> Of course, there should also be a way to make sure the native make(1) is
> used, because as of now, unless the package plays with definining
> MAKEPROGRAM directly, bmake(1) is called, and on OtherBSD, to build a
> LKM, it is likely to fail.

If it's an OtherBSD LKM, that is certainly a candidate for redefining
MAKE_PROGRAM right in that package's Makefile.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>