On Wednesday 05 December 2007 06:54:11 Johnny C. Lam wrote:
> How exactly does cmake work?  Is there a document somewhere that
> explains it?

http://www.cmake.org/HTML/About.html gives a brief summary (and links 
to other docs).

> Overriding CMAKE_MODULE_PATH to use ${PKGSRCDIR}/mk/cmake-Modules
> is interesting, but get a bit more flexibility if you made this
> directory into a set of templates that get copied into:
>
> _CMAKE_DIR=	${BUILDLINK_DIR}/cmake-Modules
>
> as part of some pre-configure hook and pass ${_CMAKE_DIR} as the
> module path to cmake.  In this way, if a particular package needs a
> slightly different or additional files, you can just put them into
> that directory without impacting other packages that use cmake.

I thought about doing that but went the way I did for simplicity
(not having to generate the overridden modules in the makefiles) till 
I had a better feel for how many standard modules were going to need 
to be overriden in every case.  But yes, having 
${PKGSRCDIR}/mk/cmake-Modules as a directory of templates that gets 
copied to ${BUILDLINK_DIR}/cmake-Modules and then have cmake use that 
tree does give more flexibility.

> > +CMAKE_MODULE_PATH_OVERRIDE?=	# empty
> > +
> > +CMAKE_MODULE_PATH_OVERRIDE+=	CMakeLists.txt
>
> The second variable definition line makes the first one irrelevant,
> so you can delete the "# empty" default.

True.

> > +################################################################
> >###### +### cmake-dependencies-rewrite (PRIVATE)
> > +################################################################
> >###### +### The cmake function export_library_dependencies()
> > writes out +### library dependency info to a file and this may
> > contain buildlink +### paths.
> > +### cmake-dependencies-rewrite modifies any such files, listed
> > in +### ${CMAKE_DEPENDENCIES_REWRITE} (relative to ${WRKSRC}) to
> > have the +### real dependencies
> > +###
> > +
> > +do-configure-post-hook: cmake-dependencies-rewrite
> > +
> > +_SCRIPT.cmake-dependencies-rewrite=					\
	[...]
> Factor this out into a standalone awk script you can stick into
> mk/configure.  This lightens the number of lines that bmake has to
> process and keep in memory.

Easily done.  I actually had it as a standalone script before I worked 
it into that makefile so I can just go back to the old version.

> Can you give an example of what a package Makefile that uses cmake
> would look like?

Sure below is the Makefile for a package for strigi:

------
# $NetBSD$

DISTNAME=       strigi-0.5.7
CATEGORIES=     sysutils
MASTER_SITES=   ${MASTER_SITE_SOURCEFORGE:=strigi/}
EXTRACT_SUFX=   .tar.bz2

MAINTAINER=     markd@NetBSD.org
HOMEPAGE=       http://strigi.sourceforge.net/
COMMENT=        Small fast desktop searching program

USE_LANGUAGES=  c c++
USE_TOOLS+=     gmake pkg-config perl
USE_CMAKE=      yes

pre-configure:
        ${LN} -sf ${QTDIR}/bin/qmake ${BUILDLINK_DIR}/bin/

.include "../../archivers/bzip2/buildlink3.mk"
.include "../../converters/libiconv/buildlink3.mk"
.include "../../devel/zlib/buildlink3.mk"
.include "../../wip/libclucene/buildlink3.mk"
.include "../../textproc/libxml2/buildlink3.mk"
.include "../../sysutils/dbus/buildlink3.mk"
.include "../../x11/qt4-libs/buildlink3.mk"
.include "../../x11/qt4-qdbus/buildlink3.mk"
.include "../../mk/bsd.pkg.mk"
-----

and below is part of the Makefile for kdelibs4 showing 
an "out-of-place" build:

-----
	[...]
USE_TOOLS+=     pkg-config perl
USE_LANGUAGES=  c c++
USE_CMAKE=      yes
CMAKE_ARG_PATH= ..
CONFIGURE_DIRS= KDE_build

pre-configure:
        ${MKDIR} ${WRKSRC}/KDE_build

CMAKE_DEPENDENCIES_REWRITE= KDE_build/KDELibsDependencies.cmake
CMAKE_MODULE_PATH_OVERRIDE+=    kjsembed/qtonly/CMakeLists.txt
	[...]
-----

cheers
mark