> 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?

> 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 :-)
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)?

> 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

where should that code be placed?
In the pkgsrc/buildlink framework? If so, I don't understand it since, IMO,
it would include libnbcompat.buildlink3.mk even for packages that do not make
use of any of its functionalities.
In eack affected package's Makefile? That I would just like to avoid, since
it would mean putting the information which OS needs which libnbcompat
features right into each such package. This is exactly what I am thinking of
avoiding. My idea is to put in each package the information which, if any,
of the features that libnbcompat can potentially supply are needed and
elsewhere globally indicate for a given OS which of libnbcompat's features
it requires (if any).

> 
> The AUTO_VARS idea comes from mk/pthread.buildlink3.mk.

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

> 
> Note also that I changed the .include file from ../../pkgtools to 
> ../../mk. The pkgtools/libnbcompat/buildlink3.mk should be kept as 
> simple as possible, while similar files already exist in the ../../mk 
> directory.

again, I am afraid I do not really understand. Which selection mechanism
should be carried out in that script? (see my above question)

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