2011/7/27 Bjørn Forsman <[email protected]>: > Hi all, > > I wonder if I've hit some bugs in the CPack generators, specifically > TGZ and DEB. They do not behave as I expect them to. What I expect > them to do is to generate an archive of files that look exactly like > what 'make install' puts in DESTDIR. If this is a wrong assumption > then please tell me.
This is a wrong assumption for several reasons but keep reading. I'll try to answer inline, for the part I do have answer :-] > So based on that assumption, here are the issues: > > 1. TGZ doesn't populate the archive with all needed parent > directories. A binary that 'make install' puts in > DESTDIR/usr/local/bin is put in <archive_root>/bin with TGZ. I would > have expected the archive to contain <archive_root>/usr/local/bin > (like the DEB generator does). Is there maybe a configuration option > for this? CPack does not use CMAKE_INSTALL_PREFIX but CPACK_PACKAGING_INSTALL_PREFIX if this variable is not defined, each CPack generator has an historical builtin value which is used. ArchiveGenerator (TGZ, ZIP, TBZ2 etc...) are using none RPM has /usr DEB has /usr if you do cpack -D CPACK_PACKAGING_INSTALL_PREFIX=/usr/local -G TGZ then you may get the wanted prefix in TGZ. > 2. TGZ fails on absolute DESTINATION paths: > CMake Error at /home/bjornfor/eraseme/build/cmake_install.cmake:44 (FILE): > file INSTALL cannot copy file "/home/bjornfor/eraseme/build/hello" to > "/usr/bin/hello". I see you point. TGZ may handle absolute install path if you set(CPACK_SET_DESTDIR ON) i.e. cpack -D CPACK_SET_DESTDIR=ON -G TGZ will make TGZ tolerate absolute install path. > (And no, I don't want to run as root just to create an archive. If DEB > can handle this so should TGZ.) DEB (and RPM) internally set CPACK_SET_DESTDIR to ON (in fact I_ON) This is not the default behavior for archive generators mainly for backward-compatibility reason, and other reason I cannot remember but you should find a lengthly discussion about that on some closed bug on the bug tracker. I may dig this if you want the precise ref. > 3. DEB won't generate a .deb with binaries in /usr/local/bin. Example: > set CMAKE_INSTALL_PREFIX=/usr/local and install(TARGETS hello > DESTINATION bin). 'make install' puts hello in /usr/local/bin but the > .deb contains /usr/bin/hello (missing 'local'). Same as 1) use CPACK_PACKAGING_INSTALL_PREFIX, this is a feature not a bug. > Maybe the last issue is by design because no packaged software should > install to /usr/local. But wouldn't it be nicer if cpack either (1) > tell users that it changed some paths, (2) error out and die or (3) be > "stupid" and allow it? > > Can anyone help me with this? Or better yet, fix it? :-) I agree that some CPack generators behavior discrepancies are puzzling at first but making it more coherent is difficult without breaking backward compatibility. Unless I'm wrong there is nothing to fix here but the CPack documentation, for which patches are welcome as well. See the discussion here: http://public.kitware.com/Bug/view.php?id=10067 And the may be sparse but existing doc on the Wiki: http://www.cmake.org/Wiki/CMake#CPack If you want to do some specific adjustment depending on the CPack generator used you may use a CPACK_PROJECT_CONFIG_FILE see doc here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 I hope this helps. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
