[CMake] CPack 101

David Cole david.cole at kitware.com
Thu Dec 23 08:27:56 EST 2010 

On Thu, Dec 23, 2010 at 8:23 AM, Johan Björk <phb at spotify.com> wrote:

>
>
> On Thu, Dec 23, 2010 at 1:43 PM, David Cole <david.cole at kitware.com>wrote:
>
>> On Wed, Dec 22, 2010 at 12:57 PM, KC Jones <kc.jones at skype.net> wrote:
>>
>>> Feeling really uneasy about putting this out there, but here goes...
>>>
>>> I have an app that I am building with cmake (2.8) on both Mac (10.6.40
>>> and Linux (Ubuntu 10.04).
>>> The app depends on some libraries (Qt4.6 (no plugins) and a customized
>>> build of Poco).
>>> I want to generate a DragAndDrop DMG installer on Mac. (a la macdeployqt
>>> + Poco lib packaging)
>>> On Linux, I want a Debian package to install the Poco libs at a minimum
>>> along with my executable.
>>> Equivalent Windows installers will be needed someday.
>>>
>>> I've reviewed the docs at
>>> http://www.cmake.org/cmake/help/cmake-2-8-docs.html
>>> I've reviewed bits and pieces on the wiki:
>>> http://www.cmake.org/Wiki/BundleUtilitiesExample
>>> http://www.cmake.org/Wiki/CMake#CPack
>>>
>>> And I just don't seem to get it. I know this is very possible.  I know
>>> this is my own problem, first and foremost.  So I'm exposing myself to
>>> potential criticism here since RTFM and "get a clue" are probably the
>>> biggest part of fixing my problem.  Im not really asking for specific help
>>> on my code - I might ask for that later.  For now I just want to vent,
>>> hopefully in a constructive way.
>>>
>>> I just don't think that CPack documentation and examples as they
>>> currently are published are sufficient or effective.
>>>
>>>
>> Neither do we:
>> http://public.kitware.com/Bug/view.php?id=10067
>>
>>
>> A few suggestions:
>>>
>>>    - More CPack example and tutorials would be very helpful.  I see from
>>>    archive searches that I'm not the first to suggest this.  The Qt example is
>>>    great, but the plugin support is overkill for most, and obfuscates much of
>>>    the rest of the example.
>>>    - A step-wise tutorial format that starts with a working build, adds
>>>    install target support, then adds CPack code would help my addled brain.
>>>     Presenting newbies like me with a fully baked end result is helpful, but
>>>    somewhat hard to digest.
>>>    - Separating the docs into different namespaces (Cmake, CPack,
>>>    CTest...) might be more effective.  I struggled a long while before finding
>>>    the install command docs (which I continue to struggle with). The atomic
>>>    layout of the docs obscures the module-level relationships.
>>>    - A glossary, please.  For instance "bundle" comes out of OS X, but
>>>    now has some CMake-specific meaning for Linux and Win that I know is very
>>>    important to me, but fully incomprehensible in my reading so far.  Oh, and
>>>    what are bundle keys?
>>>    - More meta docs please.  Somewhere in my stumbling I found a decent
>>>    diagram about how the ExternalProject module works.  I think it was on the
>>>    wiki, but I can't find it now.  I would die for something similar that shows
>>>    what install does and how it integrates with CPack.  Same goes for
>>>    BudleUtilities and other modules I've yet to discover.
>>>
>>>
>> As always, as developers we find ourselves constantly working to improve
>> what we have: fixing bugs, implementing new features, answering questions on
>> the mailing list, blogging/communicating about it, adding examples and
>> suggestions to the Wiki.
>>
>> The struggle is reserving enough time to contribute to documentation when
>> there are always "real" (functional) bugs to be fixed. Perpetual questions:
>> what's "enough" documentation?, how do we make sure people can find it
>> easily?, how do we name this better (but still preserve the existing names
>> for people already using it / backwards compatibility)?
>>
>> I make no excuses here: yes, the CPack and CTest documentation are lacking
>> / lagging behind the CMake documentation. However, it will take a very real
>> and concerted and time-consuming effort to improve the situation. With the
>> open source nature of the project, we have to be willing to accept the
>> organic growth that occurs in the code base: the documentation will be the
>> same: it will improve gradually, over time, as contributors are able to
>> improve it.
>>
>> Until then, at least the mailing list has a reasonable response rate and,
>> it seems, sufficient participation from knowledgeable folks willing to pitch
>> in and answer. So... if you're confused about something, please ask here.
>>
>> How about a search for the mailinglist archives?
>

A typical google search about "CMake stuff" yields mailing list discussions
as the top hits the vast majority of the time.

If you want to search *just* the mailing list archives, use:
site:http://www.cmake.org/pipermail/cmake


I really, really don't think we can provide you with a better search
experience than Google.

Just sayin'...


Thx,
David



>
>>
>>> One final comment, cmake is elegant in the extreme.  I can see from some
>>> of the wiki pages about how install is a merge that canonically folds
>>> multiple precursors into one uber-powerful, uber-flexible silver bullet.
>>>  Impressive I'm sure.  But harder to grok.  I'm not suggesting that this is
>>> a wrong choice.  But it is a barrier to learning.  Where there is this kind
>>> of folding of advanced features into basic operations, some care is needed
>>> to ensure the docs convey the basics clearly.
>>>
>>> WRT Cpack, what I find is that by merging it into CMake, the CPack code
>>> is declared one step away from where it is applied.  The need for careful
>>> quoting in install(CODE ) blocks is a case in point.  I'm sure this folding
>>> into a canonical, unified single CMakeLists.txt source is a good thing.  But
>>> right now I feel like I'm learning Lisp again.  Kind of mind blowing.
>>>  Wishing I had some better training wheels to break this down for me...
>>>
>>> Thanks for your indulgence.  I hope this does not offend those who've put
>>> so much into this great tool.
>>>
>>
>>
>> Thanks for your comments and questions. May we quote you on that? ("cmake
>> is elegant in the extreme ... great tool")
>>
>> We (I hope I speak for all CMake devs, here) take no offense. We welcome
>> discussion, always.
>>
>>
>> David Cole
>> Kitware, Inc.
>>
>>
>>
>>> KC Jones
>>> kc.jones at skype.net
>>> SkypeId: bernalkc
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.cmake.org/mailman/listinfo/cmake
>>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
> -Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101223/8d55c666/attachment.htm>

More information about the CMake mailing list