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

Chris Wolf cw10025 at gmail.com
Sat Aug 7 10:25:22 EDT 2010



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

...but doesn't cmake already generate a cpack config? i.e. "CPackConfig.cmake"?

Are you suggesting that I throw that away and implement my own just to do
per-generator stuff?

I know the other day you advised me to do something like this:

>   CONFIGURE_FILE("${CMake_SOURCE_DIR}/CMakeCPackOptions.cmake.in"
>     "${CMake_BINARY_DIR}/CMakeCPackOptions.cmake" @ONLY)
>   SET(CPACK_PROJECT_CONFIG_FILE
> "${CMake_BINARY_DIR}/CMakeCPackOptions.cmake")


...but does that replace or merge cpack config settings with the cmake-generated
CPackCOnfig.cmake?

I have to say, this seems confusing, although I've only been using CMake for two
days now.  On the other hand, it seems that introducing a new per-generator
prefix variable and 6 lines of C++ code may help the end-user by reducing 
the complexity of their CMake/CPake files.  I understand that it's 
important to avoid code-bloat, but I've seen enough chatter in the lists and
bug 7000, etc. which seems to support implementing this.

If not, then:

1.) How do I put in per-generator variable overrides without having
    to re-implement the CPackConfig.cmake that cmake already generates for me?

2.) With this approach, would I still only need to run "make package" (or 
    invoke cpack directly, letting it implicitly pick up "CPackConfig.cmake) 
    once per-build (i.e. not have to call cpack multiple times with 
    different options, like I do now)

Thanks,

  -Chris


More information about the CMake mailing list