[CMake] CPack 101

[Mike McQuaid]

To start with, Charm might be a good example of how to use CPack, it's
an internal tool we've written in Qt and use CPack to do all the
packaging:
https://github.com/KDAB/Charm

Check particularly the CMakeLists.txt and Charm/CMakeLists.txt for all
the CPack-relevant logic.


On 22 December 2010 17:57, KC Jones <kc.jones at skype.net> wrote:
> I just don't think that CPack documentation and examples as they currently
> are published are sufficient or effective.

I completely agree.

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

Agreed.


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

BundleUtilities is a really bad name. As I've said before, the naming
stops Windows and Linux people from finding this functionality until
they post on the mailing list or bugtracker. It's worth remembering
that 90% (if not more) people won't even get here and will just use
another tool.

BundleUtilities/GetPrerequisites should really be rolled into CPack,
I'd be pretty amazed if many people were using it outside of CPack.


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

Really what's needed is less API documentation and more workflow
documentation, perhaps based around user stories. If I just want to
set up a CMake project and build a package there should be a
step-by-step walk through the documentation.


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

Agreed.

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

I think integrating CPack into CMake is good but it hasn't been done
very well. INSTALL(CODE) is just a mess and it would be good to be
able to interact with CPack for typical usecases (e.g. use
BundleUtilities to install all dependencies of an executable only at
package time) and roll this into normal CPack syntax.

I think the biggest problem is that people complain about CPack not
being easy to use and are simply told how to do the task they've had
the problem with and the bug/mail is ignored. The problem isn't the
CPack functionality, it's accessing it and the lack of discoverability
of it's features.

I want to try and help and write patches for this stuff but I create
bugs and they are ignored and then post on the mailing list and no-one
from Kitware comments. I really appreciate that everyone is very busy
but it feels like the CPack developers think it's good enough as-is
and aren't particularly interested in attracted new contributions and
improving the project.



-- 
Mike McQuaid
http://mikemcquaid.com