On 8/7/10 11:22 AM, David Cole wrote: > On Sat, Aug 7, 2010 at 11:02 AM, Chris Wolf <[email protected]> wrote: > >> >> >> On 8/7/10 9:44 AM, David Cole 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. >>> >> >> To try to understand your approach, I created a file, >> "MyCpackConfig.cmake", >> which looks like: >> >> # keep cmake-generated settings >> include(CPackConfig.cmake) >> >> if("${CPACK_GENERATOR}" STREQUAL "PackageMaker") >> set(CPACK_PACKAGING_INSTALL_PREFIX "/tmp/local") >> endif("${CPACK_GENERATOR}" STREQUAL "PackageMaker") >> >> >> ...then I invoke like: >> >> cpack --config MyCpackConfig.cmake >> >> ...and yet, the results show that CPACK_PACKAGING_INSTALL_PREFIX was not >> overriden for PackageMaker. I am at a loss here... >> >> >> > You do not need to include(CPackConfig.cmake) -- and, in fact, you > shouldn't. > > Since you did include it, it has CPACK_GENERATOR defined to a list from > CPackConfig.cmake, rather than cpack's internal definition. (So it's never > equalling PackageMaker...) So you're not seeing your override take effect... > > The CPACK_PROJECT_CONFIG_FILE is included automatically on a per-generator > basis. It only need contain overrides. > > Here's how it goes: > - cpack runs > - it includes CPackConfig.cmake > - iterates over the generators listed in that file's CPACK_GENERATOR (unless > told to use just a specific one via -G on the command line...) > --- foreach generator, it then > - sets CPACK_GENERATOR to the one currently being iterated > - includes the CPACK_PROJECT_CONFIG_FILE > - produces the package for that generator > > This is the key: For each generator listed in CPACK_GENERATOR in > CPackConfig.cmake, cpack will *reset* CPACK_GENERATOR internally to *the one > currently being used* and then include the CPACK_PROJECT_CONFIG_FILE. > > As I said before, it's somewhat confusing, but once you get it, it does make > sense. > > So, to recap: > -- do not include CPackConfig in your CPACK_PROJECT_CONFIG_FILE > -- just run "cpack" on the command line > > I hope this gets you over the finish line, now. ;-) > > > David >
Ok, now *that* explanation did the job - thanks! I was under the impression that CPACK_PROJECT_CONFIG_FILE was going to *replace* the cmake-generated CPackConfig.cmake and that it would only be referenced once for all the cpack generators. Unless I missed it, I would recommend putting this latest explanation from you in a Wiki page. Thanks again, -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
