[CMake] CPack 101

[Mike McQuaid]

On 23 December 2010 14:30, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> Something like this perhaps:
>
> http://www.cmake.org/cmake/help/mailing.html
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Excuse my extreme ignorance, I had no idea that existed.
Subscribing!

> 1. you have some code.
>   The biggest thing that slows down adoption of new code in CMake is lack of
> testing.   New features that are not tested, are not welcome into CMake.  If
> the code has a CMake test and there is good dashboard coverage for the test,
> then the code will be adopted much quicker.  The code can be done on github
> or gitorious.org, or just a patch attached to a bug entry in the CMake bug
> tracker.  If a cmake developer can just merge in the code, and run ctest to
> test the new code, it makes it very easy to commit.

Ok, that's good to know. So the basic use-case should be to write the
code, write a test that runs it and ensure it's hooked up to ctest,
make sure it passes and then make a merge request detailing the above.

A few questions:
What platforms does it need to be tested on?
What branch should you base it off?

I wasn't sure if you guys looked at the merge requests on
Github/Gitorious, that's good to know.

> 2. You have a suggestion for a change but no code.
> I think there are two sub-cases for this as well:
>  A. You are willing to write the code yourself.
>  B. You think that someone else should write it for you.
>
> For A, you would want to get buy in from the developers and community before
> starting the code.  For this the cmake-developers mailing list would be the
> place to start.  Although, sometimes it might make sense to float the idea
> on the cmake mailing list first to see what the community things, and then
> use the developers list for implementation details.

Ok, great.

> For B, you have to do a pretty good sales job for the work to be done. You
> are basically asking for a handout.  Kitware does not directly invest in
> CMake, new features developed by Kitware come from Kitware customers
> requesting them.  So, you can hire Kitware (become a customer), or if your
> suggestion lines up with the needs of an existing customer, you might get
> lucky.  Of course Kitware people are not the only ones developing CMake, you
> might be able to convince someone else to do the work.  Either way, this is
> the hardest type of change to have made.

Sure. I'm not in this group as I'm happy to do the work myself but
that's good to know.

> 3. After each release we send out and email to the cmake and
> cmake-developers list, and ask for people to suggest the things they would
> like to see in the next release.  Here is the current list:
> http://public.kitware.com/Bug/roadmap_page.php.  Next release is scheduled
> for Jan. 10.

Cool, again, good to know.

> 4. We have directed all new bugs on the bug tracker to the cmake-developers
> list.  This allows all developers to see new issues as they come in.
>
> 5. We have made an effort to clean up old stuff in the bug tracker.
>
>
> So, if you have time that you want to spend on CMake development, join the
> cmake-developers mailing list.  Write some tested, documented code and
> contribute it.

Great, I think I understand how to do that a bit better now. It would
be great if the contents of your email above was included here:
http://www.cmake.org/cmake/project/getinvolved.html and also possibly
on your Github/Gitorious pages.

Thanks for the comprehensive reply and sorry for any criticism from my
misunderstandings above.

-- 
Mike McQuaid
http://mikemcquaid.com