hi,

> >   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.
> 
> what mechanism do you propose instead for making available to a package
> the header files it needs if not provided by the system (making at the
> same time sure not to make available a header file that should come natively
> from the system)? That's a key question to me.

  The buildlink framework makes sure that ${LOCALBASE}/include and
${LOCALBASE}/lib are not searched during package build.  Instead, the
files the package needs is linked into ${WRKDIR}/.buildlink/include
and ${WRKDIR}/.buildlink/lib, which avoids that the package picks up
other installed files it has optional support for.

  This mechanism is generic enough to allow us to link only those
files from ${LOCALBASE}/include/nbcompat needed by the package but not
provided by the system into ${WRKDIR}/.buildlink/include, so they will
be found by the compiler.  (The other files will not be found, since
${LOCALBASE}/include/nbcompat is not searched.)


> > 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.
> 
> great.
> Now the only problem I see is, as mentioned above, that if the package is
> able to find any of libnbcompat's header files it will likely find all of
> them,

  No, see above.

> which could lead to undesired effcts for systems that natively provide
> some of the functionality. Please note that nclude/nbcompat contains things
> like string.h, stdio.h, time.h, etc. which most systems would probably
> not prefer over their native version.

> I am not sure if a similar issue can occur when linking with -lnbcompat.
> Could a case occur where a libnbcompat function is used although the
> respective function is as well provided natively in some library file?

  I do not know libnbcompat well enough to answer that, but I think it
should not.  (If it does, I guess we should fix it.)

> >   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.
> 
> if I correctly understood your proposal
> ../../mk/libnbcompat.buildlink3.mk would be included by a package that needs
> at least one of the functionalities potentially provided by libnbcompat.
> ../../mk/libnbcompat.buildlink3.mk would inm turn include
> ../../pkgtools/libnbcompat/buildlink3.mk if at least one of the functionalities
> requested through LIBNBCOMPAT_NEEDED was indicated not to be available 
> natively as indicated in OS_LIBNBCOMPAT_NEEDED (would SYSTEM_... instead of
> OS_... be preferable as a name?)
> Now ../../pkgtools/libnbcompat/buildlink3.mk makes sure that -lnbcompat
> is added to LIBS (it does so right now only if FNU configure is selected,
> which I think should be waived as otherwise the package would not have a
> chance to know whether -libnbcompat was needed or not.

  Many packages don't care, as long as all functions they use are
provided.  LIBNBCOMPAT_AUTO_VARS is an easy way to achieve that: it
adds LIBS+=-lnbcompat, so if the build of the package honours LIBS,
nothing further needs to be done.  If the package cares, don't set
LIBNBCOMPAT_AUTO_VARS.  The same mechanism is used for pthread, and it
works well there.

						yours,
						dillo