On Sat, Aug 7, 2010 at 9:44 AM, David Cole <[email protected]> wrote:
> On Sat, Aug 7, 2010 at 9:26 AM, Chris Wolf <[email protected]> wrote: > >> >> >> On 8/7/10 7:14 AM, Eric Noulard wrote: >> > 2010/8/7 Chris Wolf <[email protected]>: >> >> On 8/6/10 8:55 PM, Eric Noulard wrote: >> >>> >> >>> Did you try the command line? >> >>> >> >>> cpack -D CPACK_PACKAGING_INSTALL_PREFIX="/opt" -G DEB >> >>> >> >>> it works for me. >> >>> >> >>> if it works for you may be >> >>> CPACK_PACKAGING_INSTALL_PREFIX is set to late >> >>> in the CMakeLists.txt? >> >>> >> >> >> >> Yes, I tried that about 8 hours ago: >> http://www.cmake.org/pipermail/cmake/2010-August/038785.html >> >> >> >> I have to say NOW it's working. Sorry - I suppose I was changing too >> many things at one back then >> >> and I was missing something. >> >> >> >> Ok, this issue is resolved, thank you. >> > >> > Good to know. >> > >> > [...] >> >> >> >> Sorry to beat a "deadhorse", since I see this has already been >> discussed: >> >> >> >> http://www.mail-archive.com/[email protected]/msg16180.html >> >> >> >> I think that guy had a good proposal - being able to control path >> prefixes >> >> at a per/generator level. I guess for now, I can just run cpack >> multiple >> >> times with path/generator options on the command line. >> > >> > I think you are right, command line is the current best way to go. >> > Now having a Generator Specific >> > CPACK_<GEN>_PACKAGING_INSTALL_PREFIX >> > wouldn't be that difficult to implement. >> > >> > Now when enough [wo]man power will be given in >> > http://public.kitware.com/Bug/view.php?id=7000 >> > this can be discussed. >> > >> > Re-read the bug comments and may be add your ideas there. >> > >> > And I do not think the horse is dead, we are merely waiting >> > for a jockey for ridding bug #7000 :-) >> > >> > >> >> Ok, I added a note to this bug with an example proposed code change. If >> it >> looks good, I can try it myself and if it works I can submit patches. >> >> Let me know, thanks, >> >> > You can already do what you propose with that change today: in a > CPACK_PROJECT_CONFIG_FILE > file. (Without making any C++ changes and without waiting for resolution of > issue #7000...). > > Inside that file, you can inspect the value of CPACK_GENERATOR and > set/override other CPACK_* variables. In this case, you would have as many > if() blocks as needed to set CPACK_PACKAGING_INSTALL_PREFIX to whatever > value you want for each generator. > > The CPACK_PROJECT_CONFIG_FILE file is included *at cpack time* and is > intended to give you the hook you need to do generator specific stuff. > > Perhaps the proposed change is still a good one and would make this task > easier. Although it seems silly to me to invent a bunch of new variables > when there's already a technique that could be used to achieve the task > today. We already, as you have observed, have enough "prefix" variables > floating around. I'm not sure adding more is the way to go. > > > HTH, > David > > And.... by the way. Sorry this is all so confusing (although it's not really my fault...) :-) It is the way it is because of favoring "backwards compatibility" over simplicity. And now we have a bit of a morass in there. So: we invented a way to override the stuff in this CPACK_PROJECT_CONFIG_FILE so that the defaults would still work the same way they always have, but there would be a way to make sane installers anyhow. But, I admit, it is confusing and difficult to get up to speed from zero. Cheers, David
_______________________________________________ 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
