[CMake] Why CPack does not _ALWAYS_ use DESTDIR?

Eric Noulard eric.noulard at gmail.com
Wed May 14 02:54:26 EDT 2008


I all,

I don't want to waste too much of our time on this
since I don't think it is a "must really have feature"
but I want to comment a little more.

2008/5/13 Bill Hoffman <bill.hoffman at kitware.com>:
> Alexander Neundorf wrote:
>  We have projects that use it for non-cmake parts of the build.  I don't
> want to break those projects.  In fact, the project that funded CPack is the
> one I am most concerned about breaking.

I do understand that very well, but  may be it would be
simple for those project to use a

cpack_policy mechanism which may be inspired from the cmake_policy one?
Moreover do you think it is doable for CPack to  check if
it is used with a plain CMake build (which supports DESTDIR)?

> > I actually found Erics argument that the default behaviour is not working
> for absolute install dirs with any package generator quite good.
> >
> > The rpm and deb generators are new, would it be ok to enable DESTDIR for
> these two unconditionally ? There can be nobody who relies on this behaviour
> for these two package types yet.
> >
>
>  I really don't like the idea of different defaults for different
> generators.  Hey, my stuff worked here, but not here type of stuff.

Yes you are right.
May be an acceptable solution would be to enrich the error message:
"CMake Error at cmake_install.cmake:40 (FILE):
 file cannot create directory: /absolute/path. Maybe need administrative
 privileges.
"
[when CMake runs on Unix] saying that

"If you want and need to install absolute file path
 you may have to SET(CPACK_SET_DESTDIR "ON") "

> IMO, the use of absolute dirs is a bug. :)

Yes you are pretty right.  I personnally did not cross the issue myself
but only look at this when other user raised it :)

Alex already told KDE is supporting it,
I'll add that from the unix-side of the world FHS (http://www.pathname.com/fhs/)
you find some file in /etc and there is no /usr/etc, so you sometimes
needs to DESTINATION /etc, or you need to install your file somewhere
and then trigger some "postinstall" script in your favorite packaging system
(rpm, deb, pkg ....) that will install a symlink or a copy in /etc.

Concerning the fact that you want to preserve independence between
CMake and CPack I totally agree on this. However when the CPackConfigXXX.cmake
is generated by CMake may be we can
SET(CPACK_SET_DESTDIR "ON")  ?

Would it be acceptable and/or would it work if the
Templates/CPackConfig.cmake.in is changed to include
SET(CPACK_SET_DESTDIR "ON")?

Do the project using CPack without CMake generates their
CPackConfigxxxx from the CMake template or do they
write/generate their own CPackConfigSpecific.cmake and then
call
cpack -C CPackConfigSpecific.cmake ...

Off course you decide what to do with this, my opinion concerning
packaging is that it is usually a painful (and uninteresting)
but necessary task such that I want it to have the best "default behavior".

I will have less time for mail answering for some day so
excuse me for less responsivness for a 2 weeks or so.


-- 
Erk


More information about the CMake mailing list