[CMake] [CPACK] Create package from multiple builds and project configurations

[Tristan Carel]

Hi,

I am  convince that to  reign, you have  to divide, but it  is definitly
easier for  users to get a  all-in-one package, specific  to the desired
architecture.

I have  a C++ library,  whose build is managed by CMake,  and I want
to  provide build packages for Linux, Darwin, and Windows.
For each architecture, I want to provide both the `release' and `debug'
version of this library.  I  can also choose either the STLPort library
or the STL embedded with the C++ compiler.
It makes  4 different  builds  on each architecture  and the  aim here
is to  get 1  `build' package per architecture

Under Linux and Darwin, thanks to the CPack variable
`CPACK_INSTALL_CMAKE_PROJECTS', it just has been a piece of cake.

On both computers, I  use the  "Unix Makefiles"  generator to  create
4 different builds:

CMAKE_BINARY_DIR                          CMAKE_BUILD_TYPE
/tmp/helloWorld/_build/Release             Release
/tmp/helloWorld/_build/Debug               Debug
/tmp/helloWorld/_build/Release_stlport     Release
/tmp/helloWorld/_build/Release_stlport     Debug

Then I just create a custom CPackConfig.cmake with among other SET commands:
# -----------------------------------------------------------------------------
SET(CPACK_INSTALL_CMAKE_PROJECTS
 "/tmp/helloWorld/_build/Release;helloWorld;ALL;/"
 "/tmp/helloWorld/_build/Release_stlport;helloWorld;ALL;/"
 "/tmp/helloWorld/_build/Debug;helloWorld;ALL;/"
 "/tmp/helloWorld/_build/Debug_stlport;helloWorld;ALL;/"
)
# -----------------------------------------------------------------------------

Then the  command below builds a wonderful package:
$ cpack --config CPackConfig.cmake

Everything is fine, except that I have to manually check that any file
written in the temporary installation directory is overwritten by the next
installation steps. With huge projects, it can be very annoying. Maybe warnings
would be pleasant is this case.

Before starting with the Windows mess, I need you to validate something
I am hesitant about:
The  `Unix   Makefiles'  generator  can  be  considered   as  a  `static
generator',   in  a   sense   that  the   configuration   is  known   at
`configure-time'. And that is why:
1. The command below looks at me, laugh and ignore the variable
$ make CMAKE_BUILD_TYPE=Debug all
2. The  command below  completly stifle  by  my impudence,  which is  a
consequence of the first point (CPack uses CMake install mechanism).
$ cpack -C Debug --config CPackConfig.cmake

Am I right?



Now let's talk about the funny part ... Windows!

If I  am still  right, "NMake Makefiles"  and "Visual .."   are `dynamic
generators'  as the  build  configuration is  determined at  build
time.
On this platform, I have only 2 different CMake builds:

c:/helloWorld/_build/msvc8
c:/helloWorld/_build/msvc8_stlport

(I could  also chose to make  only 1 build with  the four configurations
all-in-one)

The CPackConfig.cmake contains:
SET(CPACK_INSTALL_CMAKE_PROJECTS
 "c:/helloWorld/_build/msvc8;helloWorld;ALL;/"
 "c:/helloWorld/_build/msvc8_stlport;helloWorld;ALL;/"
)

Then, as I use a `dynamic generator', I don't have any other choice than
to specify to CPack the configuration to install:
$ cpack -C Debug --config CPackConfig.cmake

But, as CPack removes the  temporary installation directory each time you
run  the commands,  we can't  build a  package with  both  `Release' and
`Debug' build configurations, can we?

I have looked  under each documentation's stones, check  the bug tracker
but  found  nothing  about  it.  The  mailing-list  archive  contains  a
workaround, `usable' but not `checkinable'.

I guess a clean way to handle this would be to make CPack accepts a list
of configurations  (via the -C command  line option) and  install all of
them  in  the  temporary  install  directory before  running  the  CPack
generators.
You can find a patch in  attachment which implement the feature.
@Maintainers: I would be glad  to see it in  CMake some day. If  interested,
I can  help you to make this happen soon.

So right  now, it  works pretty  well, modulo the  patch (but  modulo is
still better than division :)

$ cpack -C "Release;Debug" --config CPackConfig.cmake
builds the Windows package with the expected content!

Thx for these amazing tools!
-- 
Tristan Carel
Music with dinner is an insult both to the cook and the violinist.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpack-multiple-configurations.diff
Type: application/octet-stream
Size: 5562 bytes
Desc: not available
Url : http://public.kitware.com/pipermail/cmake/attachments/20070812/e22c7687/cpack-multiple-configurations.obj