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

[David Cole]

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.


Cheers,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100807/d084d3c1/attachment.htm>