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

Chris Wolf cw10025 at gmail.com
Sat Aug 7 10:29:31 EDT 2010



On 8/7/10 9:50 AM, David Cole wrote:
> On Sat, Aug 7, 2010 at 9:44 AM, David Cole <david.cole at kitware.com> 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.
>>
>>
>> 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


More information about the CMake mailing list