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
_______________________________________________ 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
