Subject: let's finally properly integrate libnbcompat's features
To: Discussion Packages Technical List NetBSD <tech-pkg@netbsd.org>
From: Georg Schwarz <georg.schwarz@freenet.de>
List: tech-pkg
Date: 08/20/2006 11:44:02
I feel that it becomes important to have a proper mechanism for  
integrating functionalities from libnbcompat.
Libnbcompat contains a number of features that certain packages  
assume to be present, but some of which do not exist natively on  
certain platforms.
I would really love to have the following mechanism with pkgsrc (all  
variable names are just proposals; if you can come up with better  
names, please feel free to come forward with them):

* a variable USE_FEATURES, set per package as needed, which in a  
similar way as USE_TOOLS lists the features that package's code  
requires. For example, if a package's code uses snprintf() and  
assumes that the system supplies it, one would have in the Makefile

USE_FEATURES+=	snprintf

* a variable NEED_PKGSRC_FEATURES, globally set per platform, which  
lists all the features that particular platform does not provide  
natively. For example, on IRIX 5 this might look like this:

NEED_PKGSRC_FEATURES=	regex fnmatch glob snprintf vsnprintf

The appropriate place to set this is probably the respective mk/ 
platform/*.mk file?
For other platforms such as NetBSD that list would be empty, which we  
could make the default (in order not to have the need to explicitly  
set it for each and every platform).

I'm unsure which would be the best way to code that. Would it make  
sense to have an additional stage "features" similar to tools?  
(probably overkill?) Or, which I think might be more elegant, is it  
possible to integrate this into the buildlink3 mechanism in the  
wrapper stage?


The features so far are all supplied by libnbcompat.
To start with, there are features that involve specific header files  
(such as regex.h, fnmatch.h, glob.h) and those that don't.
Those headers are installed by libnbcompat in ${LOCALBASE}/include/ 
nbcompat.
If one such header is needed (because the respective feature is both  
in USE_FEATURES set by the package and NEED_PKGSRC_FEATURES set by  
the platform) it should be symlinked into  ${BUILDLINK_DIR}/include.
Is there already a buildlink mechanism we could make use of for that  
purpose?

A USE_FEATURES mechanism would make it very transparent why  
libnbcompat might be needed. Plus, it would reduce explicit platform- 
dependend code in the package Makefiles.


The code fragment I am thinking of would look something like this:

USE_FEATURES?=  #empty, set by package if needed
NEED_PKGSRC_FEATRES?=   #empty, set by platform if needed

_NEED_NBCOMPAT_FEATURES=         #empty
.for _feature_ in USE_FEATURES
.  if !empty(NEED_PKGSRC_FEATURES:M${_feature_})
     _NEED_NBCOMPAT_FEATURES+=   ${_feature_}
.  endif
.endfor

.if !empty(_NEED_NBCOMPAT_FEATURES)
. include "../../pkgtools/libnbcompat/buildlink3.mk"
.endif




_NBCOMPAT_HEADERS=      fnmatch getopt glob regex
_NBCOMPAT_HEADER.getopt=	nbcompat.h

.for _feature_ in _NEED_NBCOMPAT_FEATURES
. if !empty(_NBCOMPAT_HEADERS:M${_feature_})
_NBCOMPAT_HEADER.${_feature_}?=	nbcompat/${_feature_}.h
.  endif

[so here we need the code that will have ${LOCALBASE}/include/$ 
{_NBCOMPAT_HEADER.${_feature_}} symlinked to ${BUILDLINK_DIR}/include/ 
${_feature_}.h, only after ${BUILDLINK_DIR}/include has been created  
of course. Does the buildlink framework already provide some  
mechanism one could use for that purpose?]

. endif
.endfor


Where would be the best location to place this code?

Any feedback would be highly appreciated! Thanks.


Some examples how that functionality would be used with existing  
packages:

print/gv/Makefile would simply have USE_FEATURES+= getopt, and  
Solaris would set EED_PKGSRC_FEATURES = getopt
mail/incm/Makefile would simply have USE_FEATURES+= utimes, and  
Interix would set NEED_PKGSRC_FEATURES = utimes


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