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 <[EMAIL PROTECTED]>: > 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 _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake