Mark Davies wrote:
> 
> Anyway, on a vaguely related matter: As cmake is now being used to 
> configure/build an increasing number of packages (most obviously 
> KDE4) I've been looking at adding support for it to pkgsrc.

This sounds like an excellent idea.  I think once a particular configure 
or build method gets enough critical mass, we should try to directly 
support it in pkgsrc.

I have some comments on the patches below, but on the whole, I think 
this looks right.

> There is some initial work to get cmake to play nice with buildlink, 
> overriding its default paths to search for includes and libs but 
> thats tricky as individual packages are prone to add extra paths to 
> search in ways that are difficult to catch generically.  So currently 
> cmake is still quite prone to find things that happen to be installed 
> on your system rather than just those buildlinked but I think the 
> framework is there to improve that once get more of a feel for 
> precisely how it works.

How exactly does cmake work?  Is there a document somewhere that 
explains it?

> --- /dev/null	2007-12-05 01:58:36.000000000 +1300
> +++ mk//configure/cmake.mk	2007-12-05 01:15:35.000000000 +1300
> @@ -0,0 +1,76 @@
> +# $NetBSD$
> +
> +USE_TOOLS+=	cmake
> +CMAKE_ARGS+=	-DCMAKE_INSTALL_PREFIX:PATH=${PREFIX}
> +CMAKE_ARGS+=	-DCMAKE_MODULE_PATH:PATH=${PKGSRCDIR}/mk/cmake-Modules

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.

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

> +######################################################################
> +### 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=					\
> +	${AWK} '{							\
> +			match($$0, "_LIB_DEPENDS \"");			\
> +			if (RSTART == 0) {				\
> +				print;					\
> +			} else {					\
> +				printf "%s \"", $$1;			\
> +				d=substr($$0,RSTART+RLENGTH,length($$0));\
> +				while ( d != "\")") {			\
> +					match(d,"[^;]*");		\
> +					dep=substr(d,RSTART,RLENGTH);	\
> +					d=substr(d,RLENGTH+2,length(d));\
> +					if (dep ~ "^${BUILDLINK_DIR}") { \
> +						"ls -l " dep | getline ls_out;\
> +						match(ls_out,"-> ");	\
> +						if (RSTART > 0) {	\
> +							dep=substr(ls_out,RSTART+RLENGTH,length(ls_out)); \
> +						}			\
> +					}				\
> +					printf "%s;",dep;		\
> +				}					\
> +				print d;				\
> +			}						\
> +		}' $$file > $$file.override;				\
> +		${MV} -f $$file.override $$file

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.

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

I think your approach is very promising!

	Cheers,

	-- Johnny C. Lam