[CMake] Managing a local installation of cmake-built open source packages

[Domen Vrankar]

2017-01-18 22:37 GMT+01:00 ardi <ardillasdelmonte at gmail.com>:

> If anybody has further suggestions, please don't hesitate to tell.
>

Alternative 1:
I usually go with the platform supported packages even if that means having
more than one package format... I prefer less custom dependencies to
one-package-to-rule-them-all logic specially since most of the time
programs already have to be recompiled on each platform. For me less custom
dependencies is worth far more than having only one package type to
maintain.

Since you're saying that you can already install the files through CMake
you've already won half the battle - the installation part is basis for all
CPack packages (you set 2-3 variables and you have minimal RPM or DEB
package(s) - even component packages if install commands have components).
I don't know about the rest of the packagers but CPackRPM and Deb are quite
similar in that regard so there is not too much of a learning curve. If you
don't maintain the packages and they don't use CPack it's easy to append
the rules at the end of the root CMakeLists.txt (I did that for C++ version
of apache qpid a while back and produced minimal component RPM packages for
AIX OS in under 5 minutes).

Regarding installation on a different location as I said I'm not too
familiar with the rest of the packagers but you can create a custom package
database for both RPM and Deb packages and then install them on a different
location (relocatable RPM or a bit hackish way with Deb packages - see
LONG_FILENAMES/VerifiResult.cmake CMake test for an example with deb
packages).

Alternative 2:
You were talking about install_manifest.txt file. CPack  Archive packagier
(particularly STGZ - self extracting tar gz - version) could easily be
extended to produce such file and check for it on next install (asking you
if you'd really like to delete the content or something similar).
 Contributing something like that to CPack would even remove the burden of
maintaining a patched cpack version yourself.
Drawbacks are that you loose files database that comes with rpm/deb (nobody
will warn you if a file has been changed, was present in two packages etc.)
and also the currently-not-supported-by-cpack part (but since it's fairly
easy to implement we could probably get it into next CMake release).

Regards,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170119/ccbf8c8f/attachment.html>