On 8/7/10 9:50 AM, David Cole wrote: > 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. >
I agree that favoring backwards compatibility is important, from some of the build tools surveys I've read, this was mentioned as a strong point in favor of cmake. I pretty sure the proposed change would not break backwards compatibility. -Chris _______________________________________________ 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
