[CMake] A configure script solution

[Timenkov Yuri]

On Tuesday 24 June 2008 20:27:53 J wrote:
> Greetings all!
> 
> I've been sold on cmake. From what I gather, it's hands down better than
> automake and family. However, I do have a problem with not having a
> configure script.
> 
> A couple of the main benefits of having a configure script are letting
> the user/package maintainer choose portions of a project to compile or
> exclude from compilation, as well as choosing alternate locations for
> libraries/includes/installations, both of which are rather important.
I don't think whether I'm answering your question, but I came to some tricks :)
I have a complex project, which sometimes is convenient to build whole (as developer), but should be packaged into multiple parts which must be built independently. (like allowing to build only konqueror or whole kdebase).

1) I want to customize parts built, so I've divided whole solution into several big parts, and in top-level makefile I have:

option(MYPROJ_ENABLE_CORE "Build core libraries and plugins.")
option(MYPROJ_ENABLE_EXTRA "Build extra libraries and plugins.")

if(MYPROJ_ENABLE_CORE)
	add_subdirectory(core)
endif(MYPROJ_ENABLE_CORE)

if(MYPROJ_ENABLE_EXTRA)
	add_subdirectory(extra)
endif(MYPROJ_ENABLE_EXTRA)

This way I have 2 options: build either part or both ones. One part depends on another, so I have an options again: If user builds both parts, local variables should be used (and CMake should track dependencies), otherwise CORE part should be installed and treated as third-party software.

2) In "EXTRA" part of solution I use FindMyProjCore.cmake (via find_package(MyProjCore)) which contains something like this:

# Build with Core sources from current CVS checkout tree.
if(MYPROJ_ENABLE_CORE)
	# We do not need to search in external directories, just set dependencies
	# as they were CMake targets. This will cause automatic rebuild of dependant modules.
	set(MyProjCore_FOUND TRUE)
	set(MyProjCore_INCLUDE_DIR
		"${CMAKE_SOURCE_DIR}/core"
		)

	foreach(core_lib corelib1 corelib2 corelib3)
		set(${core_lib}_LIB ${core_lib})
	endforeach(core_lib)
else(MYPROJ_ENABLE_CORE)
	# Look for headers in distribution directory.
	find_path(MyProjCore_INCLUDE_DIR
		NAMES MainCoreFile.h
		# Find in destination install directory too, ex. "/opt/myproj/include" if core part
		# was compiled from other tree.
		PATHS
			"${MYPRJ_INCLUDE_INSTALL_DIR}"
			"${CMAKE_INSTALL_PREFIX}/${MYPROJ_INCLUDE_INSTALL_DIR}"
		)

	set(MyProjCore_ALL_LIBRARIES_FOUND TRUE)
	foreach(core_lib corelib1 corelib2 corelib3)
		find_library(${core_lib}_LIB NAMES "${core_lib}"
			PATHS
				${CMAKE_INSTALL_PREFIX}/lib
			)
		mark_as_advanced(${core_lib}_LIB)
		if(NOT ${core_lib}_LIB)
			set(MyProjCore_ALL_LIBRARIES_FOUND FALSE)
		endif(NOT ${core_lib}_LIB)
	endforeach(core_lib)

	include(FindPackageHandleStandardArgs)
	find_package_handle_standard_args(MyProjCore "Could not find Core libraries" MyProjCore_INCLUDE_DIR MyProjCore_ALL_LIBRARIES_FOUND)
endif(MYPROJ_ENABLE_CORE)

Again, I don't know whether this is answer to your question. Also, you can look how CMake handles system/internal dependencies itself (look into CMakeLists.txt shipped with CMake sources.)
> 
> Without a configure script all package maintainers for red hat/fedora,
> debian/ubuntu, etc will have to learn all the ins and outs of cmake and
> spend oodles of time setting variables and passing -D switches to cmake.
> 
> So my question to everyone is, is there already a replacement configure
> system/script that mimics or replaces the configure scripts created by
> autotools?
> 
> The KDE folks wrote a very simple configure script by hand it seems,
> which replaces rudimentary options such as --libdir and such, which is a
> start but not nearly complete enough to actually replace autoconf's
> configure scripts.
> 
> Thanks in advance for any information you can provide.
> 
> j
> 
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>