Re: cmake files in pkgsrc/mk with hard-coded /usr/pkg paths

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

Thomas Klausner writes:
 > I think just using ${BUILDLINK_DIR} where you used LOCALBASE should do
 > the trick, but I haven't tried it.

Yes, that does in fact replace the directory path with the buildlink
directory.  And my test case (sysutils/strigi) does still build fine.
However, it also builds fine when that path is replaced by a bogus
one.  Note that in both cases the following message appears:

     CMake Warning (dev) at 
/usr/pkg-2011Q2/share/cmake-2.8/Modules/Platform/NetBSD.cmake:13 (INCLUDE):
       File /usr/pkg-2011Q2/share/cmake-2.8/Modules/Platform/NetBSD.cmake 
includes
       
/home/brook/cvs-NetBSD/pkgsrc-2011Q2/sysutils/strigi/work/.buildlink/cmake-Modules/Platform/UnixPaths.cmake
       (found via CMAKE_MODULE_PATH) which shadows
       /usr/pkg-2011Q2/share/cmake-2.8/Modules/Platform/UnixPaths.cmake.  This 
may
       cause errors later on .

This leaves me wondering, under what conditions are the contents of
.buildlink/cmake-Modules/Platform/UnixPaths.cmake actually used?

In the end, using ${BUILDLINK_DIR} may be the correct thing to do, but
I'm not sure how to test for fallout of the change.  Are people
comfortable with the change and willing to help identify any
consequent problems?  Should the original proposed change (i.e.,
${LOCALBASE} along with removing /usr/local/bin) be committed instead?

On a related note, should the recent change to the cmake package
itself have used ${BUILDLINK_DIR} instead of ${LOCALBASE}?

Thanks for your help.

Cheers,
Brook