[CMake] Buggy CPack generator behaviour?

[Eric Noulard]

2011/7/27 Bjørn Forsman <bjorn.forsman at gmail.com>:
> 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