On Tue, Mar 4, 2008 at 12:39 PM, Sebastien BARRE < [EMAIL PROTECTED]> 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!) =) > > > - 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? -- Philip Lowman
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
