[CMake] still having a problem with PackageMaker, and now DEB

[Chris Wolf]

On 8/7/10 11:22 AM, David Cole wrote:
> On Sat, Aug 7, 2010 at 11:02 AM, Chris Wolf <cw10025 at gmail.com> wrote:
> 
>>
>>
>> On 8/7/10 9:44 AM, David Cole wrote:
>>> On Sat, Aug 7, 2010 at 9:26 AM, Chris Wolf <cw10025 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 8/7/10 7:14 AM, Eric Noulard wrote:
>>>>> 2010/8/7 Chris Wolf <cw10025 at gmail.com>:
>>>>>> 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/cmake@cmake.org/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