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