On Friday, April 01, 2011 02:42:53 pm Clinton Stimpson wrote: > On Friday, April 01, 2011 01:48:41 pm Crni Gorac wrote: > > On Fri, Apr 1, 2011 at 8:38 PM, Eric Noulard <eric.noul...@gmail.com> wrote: > > > 2011/4/1 Crni Gorac <cgo...@gmail.com>: > > >> Am working with seemingly not too complicated CMake setup: Have two > > >> projects, say Foo and Bar, both dependent from the library libBaz; > > >> actually at the beginning there was only Foo project, and now there is > > >> Bar project, and common code is refactored into libBaz library. All > > >> three of these are into own subdirectories, and I have top-level > > >> CMakeLists.txt, that practically contains only references to each of > > >> these subdirectories. The libBaz library is built statically and > > >> linked this way into both Foo and Bar projects, so it all works in > > >> rather simple manner. However, now I'm faced with creating CPack > > >> installers for both Foo and Baz - more precisely, there already exists > > >> CPack based installer for Foo that also works great, and now I'm > > >> looking into building same kind of installer for Bar. I've looked > > >> through the list and such, but it seems that it is not possible to > > >> have two installers generated from single CMake source tree. So - > > >> what would be recommended approach to handle this sort of setup then? > > > > > > Which version of CMake are you using? > > > Which set of CPack generator do you want to work with? > > > > > > Multiple installer on the same tree is not really handled yet unless > > > you use multi-file component-aware installers > > > (ZIP, TGZ and other archive generators, RPM and DEB). > > > > > > You can find more information about that here > > > http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack > > > > > > Now you scheme is more like the feature request described here: > > > http://public.kitware.com/Bug/view.php?id=11808 > > > > > > Have a look at that this thread too: > > > http://www.cmake.org/pipermail/cmake/2011-February/043075.html > > > > > > So basically CPack does not currently support multi-package besides > > > the component things. If you want to join the effort to make it happen > > > please do so by throwing idea (on the mailing list or tracker) > > > and/or patch on the bug tracker. > > > > Thanks for replies. I'm using CMake 2.8.4, and for this particular > > project - it's mostly about PackageMaker and NSIS installers (for Mac > > and Windows, respectively). Also, CPack components stuff is really > > not usable here, these are two projects with completely separate > > target audience, but sharing lots of the underlying implementation > > through this library of common code. > > > > @Clinton: Care to explain the setup you mentioned (with multiple CPack > > config files) in more details? > > > > Also: if CPack not supporting the setup I've described, and if I just > > split the whole thing into three different projects, what would be the > > best approach with CMake to assure that common library get built when > > building any of projects depending on it? Or developer just have to > > remember to build the library manually first, and then these two > > projects? > > I think CPack should work fine for your setup. > Here's a function you can use: > > function(create_cpack_config filename) > set(CPACK_OUTPUT_CONFIG_FILE "${filename}") > INCLUDE(CPack) > endfunction(create_cpack_config) > > Then an example of using components to control what goes in the packages: > > set(CPACK_COMPONENTS_ALL Common Unspecified Foo) > set(CPACK_PACKAGE_FILE_NAME "Foo") > create_cpack_config(CPackConfig-Foo.cmake) > > set(CPACK_COMPONENTS_ALL Common Unspecified Bar) > set(CPACK_PACKAGE_FILE_NAME "Bar") > create_cpack_config(CPackConfig-Bar.cmake) > > Use "Common" as a component for install() rules for common code, and use > "Bar" or "Foo" for package specific install() rules. And still keep > everything under one source tree.
Or even simpler, don't add a COMPONENT option for common install() commands, and let the "Unspecified" in set(CPACK_COMPONENTS_ALL Unspecified Foo) put common stuff in the Foo package. > > > Or you may be able to create packages ignoring components but specifying > sub- directories under a single tree (if this is the kind of layout you > have): > > set(CPACK_INSTALL_CMAKE_PROJECTS "${Foo_BINARY_DIR}" "Foo" "ALL" "*") > set(CPACK_PACKAGE_FILE_NAME "Foo") > create_cpack_config(CPackConfig-Foo.cmake) > > set(CPACK_INSTALL_CMAKE_PROJECTS "${Bar_BINARY_DIR}" "Bar" "ALL" "*") > set(CPACK_PACKAGE_FILE_NAME "Bar") > create_cpack_config(CPackConfig-Bar.cmake) > > Then use the --config option to cpack to build the packages. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake