[CMake] CMakeModules repository at GitHub?

Jean-Christophe Fillion-Robin jchris.fillionr at kitware.com
Thu Mar 28 12:34:40 EDT 2013


+1


On Thu, Mar 28, 2013 at 12:25 PM, David Cole <dlrdave at aol.com> wrote:

> CMake needs no new Find modules.
>
> All projects should provide a "project config file .cmake script" readable
> by CMake's find_package, and installed in a location where CMake can find
> it, so that a CMake find module is completely unnecessary.
>
> For other types of module improvements, I think becoming a CMake developer
> and participating in the active development of CMake itself is a much more
> useful thing than having a separate repository for stuff like this.
>
> This is just my opinion, and I would love to hear what others think. But
> you'll be hard-pressed to convince me that a find module inside CMake
> itself is better than a config file installed with a project's install tree.
>
>
> David C.
>
>
>
> -----Original Message-----
> From: Mateusz Loskot <mateusz at loskot.net>
> To: cmake <cmake at cmake.org>
> Sent: Thu, Mar 28, 2013 8:44 am
> Subject: [CMake] CMakeModules repository at GitHub?
>
>
> Hi,
>
> To CMake maintainers,
> what do you think about creating new repository at
>
> https://github.com/Kitware/**CMakeModules<https://github.com/Kitware/CMakeModules>
>
> as incubator for contributed CMake modules?
>
> Here is outline of the process I'm thinking of:
>
> 1. I have developed new module for find_package
> 2. I submit pull request adding this new module to CMakeModules
> - this is effectively act of request for comments and review
> 3. The module undergoes cycle of community-based review-improve-review
> iterations
> 4. The module collects +1 votes
> 5. Once some sort of critical mass of +1 has been received,
> the module is added to CMakeModules repo
> 6. The newly added module gets stamp "CMake Approved"
>
> Next, users can report bugs, submit improvements through pull requests
> or even issues marking module is out of date and requires maintenance.
> GitHub is a tiptop venue for such thing.
>
> IMO, CMake modules have suffered of the issues of fragmentation
> and distribution, and it's time to apply "Stop Rolling Your Own" [1]
> approach, and perhaps stream all those precious efforts into one sink.
>
> [1] http://ithaca.arpinum.org/**2013/01/02/git-prompt.html<http://ithaca.arpinum.org/2013/01/02/git-prompt.html>
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>
>  --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>



-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130328/77eb20f2/attachment.htm>


More information about the CMake mailing list