[CMake] still having a problem with PackageMaker, and now DEB
David Cole
david.cole at kitware.com
Sat Aug 7 11:22:12 EDT 2010
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100807/11944a8e/attachment.htm>
More information about the CMake
mailing list