2017-01-18 22:37 GMT+01:00 ardi <ardillasdelmo...@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
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
