In article <E1Ehlsm-0006IX-C1@mikro.physik.TU-Berlin.DE> Georg wrote:
: > It's not specific to this thread, but I would like the PLIST "variables" 
: > to have a certain naming convention. NEED_REGEX_H is fine for Makefiles, 
: > but in PLIST I'd like it to be called IF_NEED_REGEX_H:

: OK, that should not be a big issue.

: What is your opinion in general on the symlinking/PLISTing approach to
: enable certain select libnbcompat functionality for a given system?

  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.

: > need this in not-just-a-few packages, so maybe a little syntactic sugar 
: > is appropriate in this situation. The scheme in general looks good.

: proposals would be welcome :-)

 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

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.

: In particular, should one use new variables for that purpose or use the
: options scheme (in this case it would be global options, potentially
: set by pkgsrc)?

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

: > I think using libnbcompat's functions should be made a little easier, 
: > for example by saying:
: > 
: > .if ${OPSYS} == "IRIX" && !empty(OS_VERSION:M5.*)
: > LIBNBCOMPAT_NEEDS_HEADERS+=    regex.h fnmatch.h
: > LIBNBCOMPAT_AUTO_VARS=         yes
: > .include "../../mk/libnbcompat.buildlink3.mk"
: > .endif
: > 
: > The AUTO_VARS idea comes from mk/pthread.buildlink3.mk.

: could you please elaborate? What is that AUTO_VARS idea about?

  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.

					yours,
					dillo