[CMake] CPack and building installers for sub-projects

[Clinton Stimpson]

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.noulard at gmail.com> 
wrote:
> > > 2011/4/1 Crni Gorac <cgorac at 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