Georg Schwarz wrote:
> 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

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:

${IF_NEED_REGEX_H}include/regex.h

To me, this just _sounds_ good when reading it aloud. :)

> 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

This looks quite ugly, although it is straight-forward. We are going to 
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.

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

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.

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.

Roland