[CMake] Finder repository

Pau Garcia i Quiles pgquiles at elpauer.org
Mon May 26 07:32:40 EDT 2008


Quoting Andreas Schneider <mail at cynapses.org>:

> Pau Garcia i Quiles wrote:
>>
>> The problem with a restricted-access repository is we would   
>> probably have the same issues we have now: you need to ask for   
>> access, which would not be granted to you until you are   
>> "well-known" and/or you've got some really interesting   
>> contribution. Not a big improvement, IMHO.
>>
>
> You don't know how git works, don't you? You can send a patch or let
> the maintainer pull from YOUR repository. It's much easier than svn or
> cvs.

I know how git works (and mercurial, too, by the way) but I don't see  
people setting up their own git repositories just for other people to  
pull two FindWhaterEver.cmake.

Even if people really interested in sharing their finders would up git  
repositories, we still have the search and quality problems

* Search: while searching for a FindXXXX.cmake, you would visit a lot  
of repositories one by one

* Quality: as you don't know how many people downloaded that  
particular finder, you've got no way to know if that particular  
FindXXXX.cmake is good or bad because you would not know how many  
people downloaded it.

The search problem would be easily solved by a CMakeForge. What it  
uses to store the finders is not important, it could perfectly be git  
instead of just plain files as SourceForge, RubyForge, etc do.

The quality problem is trickier. I know "number of  downloads" is not  
the best quality measure but it's better than nothing. Ideally,  
finders should be rated by people using them. In fact, CMake could try  
to do the rating itself, using an approach similar to the  
popularity-contest package in Debian: take a SHA1 sum of every  
unofficial finder and submit it to cmake.org, and show how many people  
are using it (this should be optional, of course). Maybe show the "top  
20" unofficial finders in the front package of cmakeforge.cmake.org.

>> I'd like to propose a huge change: let's have a SourceForge-like   
>> site (what about CMakeForge at http://cmakeforge.cmake.org ? )
>
> Then we have the same as we have now. Several hundered projects with
> the same FindXXX.cmake modules and each project has its own copy.

The problem with having a single centralized repository is triage. Who  
is going to decide which finder for a particular library is the  
"official unofficial" finder? After seeing the infinite thread about  
FindBoost.cmake I'm not sure that could be managed in a proper way for  
a large number of finders.

The easy way to sort that problem is let it solve by itself: if there  
are 5 FindBoost.cmake in CMakeForge, I'd probably go for the  
most-downloaded one (or the most-used one, if cmake-popularity-contest  
is implemented).

Talking about Boost, now that Boost is moving to CMake, has anyone  
asked them to "bless" FindBoost.cmake? (AFAIK they don't provide one  
yet)


-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)



More information about the CMake mailing list