[CMake] Using multiple config names in a single project

[Karl Wallner]

Timenkov Yuri schrieb:
> I don't think it is correct.
Surely everything is correct, but things are somehow inconsistent.
(Take a look at the example attached to my previous mail: Using Unix
Makefiles installs one executable, NMake Makefiles installs two
executables and CMake 2.4 (Unix+NMake) installs three executables.)

> Better, you should pass configuration which you want to install to cpack.
> For your solution, I suppose you need more elaborate build process. 
> While VS can do this job for you, on Unix you should (manually) 
> explicitly build all of your configurations. That is: (this usually 
> should be done with script of course)
> 1) create build directory for every your configuration:
> build-debug, build-release, etc.
> 2) configure and build your project in each directory.
> 3) Tell cpack to install from every build directory. That is you should 
> explicitly write your cpack configuration file (which CPack.cmake 
> usually does for you), which installs from different build trees. You 
> can tune your CPackConfig.cmake (the generated default one), look how 
> your project installed. Usually it is something like this:
> 
> SET(CPACK_INSTALL_CMAKE_PROJECTS "/home/andy/vtk/CMake-bin;CMake;ALL;/")
> 
> You should write more quadruplets for each your configuration (look at 
> http://www.cmake.org/cmake/help/cmake2.6docs.html for more information).
> And I looked at your CMakeLists.txt: you shouldn't use 
> SET(CMAKE_BUILD_TYPE "Release") in each directory. It is better to play 
> with configuration-specific names (see DEBUG_POSTFIX and *|OUTPUT_NAME 
> target properties in link above).|*
The CPACK_INSTALL_CMAKE_PROJECTS option sounds interesting, but I doubt if it
is what I need.

The project I'm working on is a set of libraries and some addional developer 
tools. It is layed out like this:
libA/debug_shared (differnet libraries built from libA)
libA/debug_static
libA/release_shared
libA/release_static
libB/...
bin/utility1 (Utility programs, configured to linked against shared release)
bin/utility2

Under 2.4 everything worked fine setting "CMAKE_BUILD_TYPE" for each directory.
It should be possible to make 2.6 somehow compatible with 2.4.

This project was the first one for which cmake was used. It was not easy to 
convince my customers to install and use cmake (some still maintain their own
makefiles or vs projects). Now as Linux systems with cmake 2.6 (Ubuntu 8.04 and
Debian Lenny) come with cmake 2.6 preinstalled the build process does not work 
as required any more.

I'm using cmake because it does the build job very nicely. I would consider 
using and maintain build scripts as a step backwards. The power of cmake is
to be portable and to support the complete build process (config,build,pack)
on its own and to not depend on scripting features of the OS used.


Regards

Karl