[CMake] CPack different libraries in DEB compared to RPM

[Andreas Mohr]

Hi,

On Wed, Jan 30, 2013 at 08:45:31AM -0500, cmake-request at cmake.org wrote:
> Date: Tue, 29 Jan 2013 19:06:27 +0100
> From: Eric Noulard <eric.noulard at gmail.com>
> Subject: Re: [CMake] CPack different libraries in DEB compared to RPM


> 2013/1/29 upprc04 <upprc04 at gmail.com>:
> > I'm running across an issue where I have some utility libraries that are only
> > needed in the debian.  I currently have them added to both the debian and
> > RPM using CPack and CMake.  What would I need to change in my CMake files to
> > include a specific set of libraries to only be included in the debian and
> > not included in the RPM.
> 
> You "just" have to not install (or even not build) the deb-specific part when
> building for RPM.
> 
> It is easily done with separate build-tree,
> 
> You may use CPACK_PROJECT_CONFIG_FILE and
> override CPACK_INSTALL_CMAKE_PROJECTS in RPM/DEB specific sections.
> In that later case you need to define appropriate COMPONENT (see
> install(... COMPONENT...)
> argument ) in order to be able to install only the needed ones in each case.

Exactly.
My opinion is that DEB/RPM switching is best done by building and packaging
on the actual most compatible system only (rather than using foreign-package
creation on very foreign systems, i.e. multiple more or less "foreign"
CPack generators).
Separate systems of course directly translates into separate build trees, too.
Thus there's no problem in either adding distribution detection heuristics
to CMake configure-time, perhaps via find_file(/etc/debian_version)
(to skip build / install() of the affected library),
or to fix it up at CPack time, via a user-custom CPackOptions.cmake
(I think) file.


Also, note that building should in most cases be done on the *oldest*
(or perhaps near-oldest?) system version which is desired to be supported,
not a dangerously new one (reason being that backwards compatibility
support to old packages is far more commonplace/easier than
rather spotty forward compatibility).

Of course ideally one would offer precisely tailored packages via each
version of these systems, but that's a large overhead
that's probably a pipe dream in many situations.

Andreas Mohr