[CMake] cmake community site

Wed Mar 5 09:20:45 EST 2008

On Wed, Mar 5, 2008 at 12:55 AM, Philip Lowman wrote:
> On Tue, Mar 4, 2008 at 12:39 PM, Sebastien BARRE wrote:
> > At 3/3/2008 03:34 PM, Matt Williams wrote:
> >
> > >I'm looking to see what you guys on this list think about me starting up
> > >a 'cmake community' site, possibly featuring the following:
> >
> > I think I agree with the other posters, this might be a little too
> > soon. Thanks for your input though.
> > We are actually reworking a few of our websites at Kitware (see
> > http://cdash.org/), maybe CMake is on the list.
>
> Very nice!  I'm glad to see that someone is working on a replacement for
> Dart2 (and it looks prettier too!)  =)

I installed it and ran a test and it works rather nicely... this is
one of the things that could probably use some help from the community
in documenting it in the wiki. Unfourtunately, I know most of us never
find the time for domcumenting when there are more fun things to do...
:)

> > >  - A repository of Find*.cmake files including the ability to
> > > provide feedback
> > >    to the module writer, such as improvements/patches
> > >  - A repository of extra macros providing the same as the Find*.cmake
> > >    repository
> >
> > OK this one is tricky and has been debated internally in the past.
> > There are maintenance concerns here. We are strongly committed to
> > software quality at Kitware (not just for CMake), and that involves
> > compiling and *testing* our code automatically on as many platforms
> > as possible, every night
> > (http://public.kitware.com/dashboard.php?name=cmake). If it is not
> > tested, well, it is buggy (and if it's not buggy, it is soon going to
> > be out of sync). Now it is already difficult to test all the modules
> > that are in the CVS currently; they are usually exercised by our
> > other internal projects when they invoke those modules during their
> > own nightly regression tests. CMake is trying hard to be backward
> > compatible but some modules also rely on the state of the given
> > third-party tool or library they are trying to "enable": those
> > modules need to be updated to follow the progresses of both CMake and
> > said third-party tool. Now if you were to store modules in an
> > external repository, I'm pretty confident by experience that without
> > proper testing and maintenance, they would soon become unusable. It
> > would be a concern if the community was to download those modules,
> > find out they don't work, and blame CMake for it.
>
> This is a good point.  I honestly don't think a 3rd party repository is a
> good solution either.
>
> The real issue here is Modules, and there not being enough of them.  Kitware
> obviously has more important things to be doing than trying to merge in or
> support some CMake module that they didn't write and that uses 3rd party
> software they may never even have heard of.  I don't know about other CMake
> users, but I'd much rather see Bill's time occupied doing the more important
> things like architecting the future of CMake, adding features, and fixing
> bugs as opposed to dealing with Find Modules.
>
> If the issue is Kitware's reputation for software quality, the problem could
> be solved in a number of ways.  One way might be for Kitware to allow the
> community free-reign to integrate new CMake modules into a subdirectory of
> the Modules folder.  Then if a Module become stable and more depended on,
> Kitware could exercise its right to promote it into the "officially
> supported" directory.  In this way it could be a lot like how Ubuntu deals
> with their "Universe" repository, largely trusting a volunteer body (the
> MOTU) to keep the more infrequently used packages in line.
>
> Whether the subdirectory would be part of the CMAKE_MODULE_PATH by default
> is rather immaterial.  To start off with it probably wouldn't be.  It would
> be something that CMake users could opt into if they so chose, with the
> understanding that Kitware would have no obligation to support anything
> checked into it.  The important thing is that there would be a melting pot
> where modules could be integrated, tested, and improved without Kitware
> having to do much at all.
>
> Thoughts?

I thought about this and agree that a 3rd party repository is not the
solution... Sebastien and Philip have already touched upon very good
reasons why not.

Now, how about having a sandbox like in boost. It could be the
subdirectory in Modules that Philip mentions or in some other place,
but it shouldn't be in the CMAKE_MODULE_PATH by default, and it should
be a revision controlled folder maintained by the users who believe
they have some useful find module to contribute. The idea is that to
promote it for inclusion into CMake the author would need to open a
mantis feature request and submit it for review from the community or
maybe some official maintainers committee selected by the kitware
folks or whatever. I don't really know what the boost policy is and
what policy we should follow, but it looks like Bill, Brad and other
busy folks from kitware won't be able to review every module since
that is the whole point of having this sandbox... I guess this is
extending the idea of the module maintainers list.

After each review the author would need to implement changes and when
the community/committee agrees that it is in shape and according to
standards then it can go up for CMake inclusion.

Thoughts?

--Miguel