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.
cpack-multiple-configurations.diff
Description: Binary data
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
