builtin INCOMPATs

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2019-10-31 at 15:05 GMT, Jonathan Perkin wrote:

> Module Name:	pkgsrc
> Committed By:	jperkin
> Date:		Thu Oct 31 15:05:52 UTC 2019
> 
> Modified Files:
> 	pkgsrc/devel/gmake: options.mk
> 
> Log Message:
> gmake: Unbreak PREFER_PKGSRC circular dependencies.
> 
> Just because a builtin is available does not mean a user has configured their
> system to use it.  Check for USE_BUILTIN instead of IS_BUILTIN to ensure both
> the builtin is available, and the user has allowed pkgsrc to use it, before
> enabling.

This was caused by fallout from the gettext-lib builtin.mk change,
previously on SunOS IS_BUILTIN.gettext was set to "no", but after the
ngettext change it is now reporting "yes", even though the builtin
implementation is not compatible with GNU.

It got me to thinking why the various builtin.mk files that support an
_INCOMPAT_* setup set USE_BUILTIN.foo=no instead of IS_BUILTIN.foo=no.
I get the feeling they've all just been copying from each other rather
than intending to do this.

I would have thought that if we're definining something as
incompatible, we'd want to do that as early as possible, and we should
instead switch to using IS_BUILTIN.foo=no, avoiding any issues with
PREFER_* interfering with USE_*, not to mention it being confusing for
users trying to debug a builtin issue which is often confusing enough.

I can cook up a patch and test it in a bulk build, but just wanted to
see if anyone had input on this first.

Thanks,

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com