[CMake] Packaging Best Practices for Linux

Andreas Pakulat apaku at gmx.de
Wed May 16 15:03:25 EDT 2012


Hi,

On Wed, May 16, 2012 at 8:19 PM, Michael Jackson <
mike.jackson at bluequartz.net> wrote:

>
> On May 16, 2012, at 1:50 PM, Andreas Pakulat wrote:
>
> > Hi,
> >
> > Am Mittwoch, 16. Mai 2012 schrieb Michael Jackson :
> >  We have a small open-source project (http://dream3d.bluequartz.net)
> where we are currently releasing binaries for Windows and OS X but not for
> Linux due to our lack of knowledge on how to properly release them. Our
> project depends on the following projects:
> >  Qt 4.7 (I think it will run with 4.6)
> >  Qwt 5.x
> >  Boost (About any version will work)
> >  HDF5 v1.8.x
> >
> >  I would like to release linux binaries but I am not really sure what
> cmake code I need to make sure CPack includes all the proper libs and
> support libs. I currently build on OpenSuse 12.1 but can fire up about any
> linux distro that people think is "better" suited for this task. Do I
> release rpms? Tar.gz? Any guidance from those in the know would be just
> wonderful and very much appreciated.
> >
> > If you use the bundleutilities module, it should be fairly simple to get
> a tar.gz or so containing the binaries (should, since I haven't done that
> myself yet). For distribution-native (deb, rpm, ...) packages the
> generators will need to be told about the dependencies, in particular how
> the various packages are named in the distribution. Those distro-packages
> will then only have your own projects binaries. If the project is
> open-source, the distributions mit also be willing to do the packaging and
> ship them with their releases. Then you'd merely need to provide source
> packages for them.
> >
> > Andreas
>
> Andreas,
>   Thanks for the ideas. I use bundleUtilities for OS X but not for Linux.
> I should adapt my code to also include Linux. One of the issues I have is
> that I have an HDF5 and Qwt "external" libraries that I compiled myself
> that I need to include.


Did you modify the source code of those libraries? If not, then using the
distro-versions shouldn't be a problem - provided they're new enough to
contain all the features you use (or bugfixes you need). If you did modify,
you should just use BundleUtilities to include them into your binary and
not ship a .deb or
.rpm, but just a tar.gz. Such a binary-tar.gz usually contains the main app
and all necessary shared libs (and data of course), packaged together and
setup up via RPATH/RUNPATH so the shared-libs are preferred over any
versions that might be installed from packages. At least thats how things
work on Linux. The package can be relocatable by using the $ORIGIN-variable
for RUNPATH and a path relative to the binary executable.

If you need to support platforms that do not support RPATH/RUNPATH the
usual thing to do is to provide shell scripts setting the LD_LIBRARY_PATH
variable so that the bundled shared libs are found.


> Maybe I should just install the version that "ships" with my linux Distro
> and then make that a requirement to compile my code? Is that what is
> typically done on Linux?


If the version in your distro is sufficient thats usually best, since it
means less potential problems due to mixing possibly incompatible system
and packaged libraries. On Linux though many people don't mind simply
compiling from source, if thats easy enough to do...


> Are there examples on the Wiki or anywhere else that shows how to setup
> everything needed for a .deb or .rpm? I am basically very new to this and
> just need to be pointed in the right direction to get some sort of recipe.
>

A quick search on the CMake wiki turns up these:
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack
http://www.cmake.org/Wiki/CMake/CPack/Examples/Linux/DEB
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

And there's of course the cpack manual:
http://www.cmake.org/cmake/help/v2.8.8/cpack.html

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120516/68a0ef1f/attachment.htm>


More information about the CMake mailing list