help with CMake on win32

Brad King brad.king at kitware.com
Tue Feb 7 19:22:16 CET 2006


Alexander Neundorf wrote:
> The usual style with cmake, unsermake, autotools etc. is:
> 
> 1) check the system
> 2) build
> 3) install
> 
> It is of course possible to implement something which will build kdelibs/win/ 
> first, then check, then build the rest. Everything else will be non-standard, 
> hard to understand and IMO hacks. 
> (Maybe something not too ugly could be done with ctest ?)

There are at least two ways to fully build a subproject during the CMake 
configure stage:

1.)  Use this form of the TRY_COMPILE command:

          TRY_COMPILE(RESULT_VAR bindir srcdir
                      projectName <targetname> <CMAKE_FLAGS <Flags>>
                      <OUTPUT_VARIABLE var>)

This will build an entire project using the given build directory and 
source directory.  Unlike the other form this does not remove the build 
tree after completing the test.  See this CMake test for an example:

http://www.cmake.org/cgi-bin/viewcvs.cgi/Tests/ExternalOBJ/CMakeLists.txt?rev=1.4&root=CMake&view=markup

2.)  Use the --build-and-test option of ctest in an EXEC_PROGRAM or 
EXECUTE_PROCESS command.

Option #1 will automatically make sure the subproject is built with the 
same compiler settings as the calling project.  Option #2 will require a 
bunch of arguments passed to ctest to tell it what compiler settings to 
use, but it may be more clear to readers of the code what it is doing.

> Right now kdewin32 is not an external lib and tied to stuff from kdelibs (like 
> including some headers from outside kdelibs/win/). So for now I strongly vote 
> for hardcoding the provided functions in ConfigureChecksWin.cmake.
> Once kdewin32 is independent from the rest of cmake, it will be easy to build 
> it separatly.

I agree.  We should get kdelibs building with its own copy of kdewin32 
first, and then separately pursue splitting the library out.

-Brad


More information about the Kde-buildsystem mailing list