>   I don't think symlinking these headers into ${LOCALBASE}/include is
> a good idea, since they don't work without also linking against
> libnbcompat.  I would let the buildlink framework take care of making
> the required haeder visible for packages that need them.

what mechanism do you propose instead for making available to a package
the header files it needs if not provided by the system (making at the
same time sure not to make available a header file that should come natively
from the system)? That's a key question to me.

> 
>  I would suggest creating tags for each (group of) function(s)
> provided by libnbcompat, and then specifying which the packge needs in
> the package's Makefile (inspired by Geert's suggestion):
> 
> LIBNBCOMPAT_NEEDED=	regex fnmatch
> .include "../../mk/libnbcompat.buildlink3.mk

looks fine to me. Further candidates are snprintf, vsnprintf, glob

> 
> mk/libnbcompat.buildlink3.mk will then figure out which of these
> functions is missing (e.g. by consulting OS_LIBNBCOMPAT_NEEDED which
> is set by the platform mk files), symlink the missing headers into
> ${WRKDIR}/.buildlink/include, and include
> ../../pkgtools/libnbcompat/buildlink3.mk if any functions are missing.

great.
Now the only problem I see is, as mentioned above, that if the package is
able to find any of libnbcompat's header files it will likely find all of
them, which could lead to undesired effcts for systems that natively provide
some of the functionality. Please note that nclude/nbcompat contains things
like string.h, stdio.h, time.h, etc. which most systems would probably
not prefer over their native version.
I am not sure if a similar issue can occur when linking with -lnbcompat.
Could a case occur where a libnbcompat function is used although the
respective function is as well provided natively in some library file?

> 
>   The options framework is for user-settable options.  The user cannot
> choose which function his OS provides.

OK, this policy wasn't that clear to me so far, in particular with respect
to the inet6 option. Anyway, the variables proposal you made above seems
very good to me since it is transparent, extensible and compact at the
same time.
> 
>   IF set to YES, -lnbcompat will be added to LIBS if libnbcompat is
> used.  This reduces the amount of work needed for packages that heed
> this variable.

if I correctly understood your proposal
../../mk/libnbcompat.buildlink3.mk would be included by a package that needs
at least one of the functionalities potentially provided by libnbcompat.
../../mk/libnbcompat.buildlink3.mk would inm turn include
../../pkgtools/libnbcompat/buildlink3.mk if at least one of the functionalities
requested through LIBNBCOMPAT_NEEDED was indicated not to be available 
natively as indicated in OS_LIBNBCOMPAT_NEEDED (would SYSTEM_... instead of
OS_... be preferable as a name?)
Now ../../pkgtools/libnbcompat/buildlink3.mk makes sure that -lnbcompat
is added to LIBS (it does so right now only if FNU configure is selected,
which I think should be waived as otherwise the package would not have a
chance to know whether -libnbcompat was needed or not.

To me there is no additional autovars mechanism needed, is there?

-- 
Georg Schwarz    http://home.pages.de/~schwarz/
 georg.schwarz@freenet.de  +49 178 8545053