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

[David Cole]

On Sat, Aug 7, 2010 at 11:55 AM, Chris Wolf <cw10025 at gmail.com> wrote:

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


Excellent! I am now officially done for the weekend. :-)

Would you recommend a certain location on the Wiki? i.e. -- were you looking
someplace for this, and found a place where you think such an explanation
should go...? I'll be happy to add this to the Wiki, but frequently, I'm not
sure where to link stuff from. If I knew around where you were looking,
maybe that would be the right place to link from to get to the new Wiki
page.

If you give me a hint about where, I'll add this to the Wiki next week
sometime.

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