Zitat von Pau Garcia i Quiles <[EMAIL PROTECTED]>:
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.
I have some around, too, but would not do that, either. Simply because
not all have a server at hand to do that.
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
Indeed. Additionally, not all are generic enough, often written for
that particular project's needs.
* 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.
People have to download it even before seeing that it's unusable.
Additionally, a rating system is not worth it. Instead, let people
report bugs and submit patches, independent of the original author.
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.
Or "trac" (has plugins for almost every VCS out there).
The quality problem is trickier. I know "number of downloads" is not
the best quality measure but it's better than nothing.
Feedback in form of bug reports give is much better. I don't know if
there is a system with a rating mechanism.
However, quality is not really that important, it must be generic enough.
You could reduce the number of FindXXX.cmake files considerably, if
the pkg-config support would be better by producing a full-path
XXX_LIBRARIES, etc. like normal FindXXX.cmake modules do. I hate to
write FindXXX.cmake modules that are only wrappers to achieve that :-(
CMake needs a better integration with other systems of finding such
definitions, IMHO. On good thing would be to make pkg-config usage
absolutely transparent, maybe even .la from libtool. That would make
many find modules obsolete.
HS
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake