There are a number of header files such as regex.h or fnmatch.h some of
which might notr exist on a given system. Since pkgsrc assumes their
existence libnbcompat does provide them.
The problem is that they are normally not "activated", i.e. accessible
to compiler through the standard pkgsrc include proceduce, which is
normally a good thing since the native version, if it exists, should be
used.
I would like to discuss a mechanism that selectively allows to activate
the libnbcompat version on a given system, if needed there.

Let's take the example of libregex and regex.h
First, we need a respective global variable (say NEED_REGEX_H) or option
(say need_regex_h). I am not sure what there current policy is, but
that's not the primary concern here (though it would be nice if someone
could clarify this).

This option/variable could be set in the respective platform file which
an option to override it in the local mk.conf, say (for IRIX):

.if !empty(OS_VERSION:M5*)
NEED_REGEX_H?=YES
.endif

which tells pkgsrc that IRIX 5 does not come with a native regex.h.

etc.


Now libnbcompat should have in some post-install (or is that too late?)
stage:

.if defined(NEED_REGEX_H) && !empty(NEED_REGEX_H:M[Yy][Ee][Ss])
${LN} -s nbcompat/regex.h ${PREFIX}/include/regex.h
.endif

(or should that be ${LOCALBASE} instead of ${PREFIX}?)


In Addition, PLIST would have an extra entry

${NEED_REGEX_H}include/regex.h

libnbcompat's Makefile would finally need

.if defined(NEED_REGEX_H) && !empty(NEED_REGEX_H:M[Yy][Ee][Ss])
PLIST_SUBST+=   NEED_REGEX_H=
.else
PLIST_SUBST+=   NEED_REGEX_H="@comment "
.endif


and just the same for other features/header files.

Of course the bootstrap script needs a comparable logic since it
initially installs libnbcompat.


A package requiring, say, regex.h and fnmatch.h would get some code like
this:

.if (defined(NEED_REGEX_H) && !empty(NEED_REGEX_H:M[Yy][Ee][Ss])) \
 || (defined(NEED_FNMATCH_H) && !empty(NEED_FNMATCH_H:M[Yy][Ee][Ss]))
.include "../../pkgtools/libnbcompat/buildlink3.mk"
.endif

if it is not using GNU configure it might also have to deal with adding
${BUILDLINK_LDADD.libnbcompat} to LIBS and making sure LIBS is used
adequately to link the package.
IMHO that could consitute a transparent, extensible and easy to use
method.

Feedback on that idea would be very welcome.

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