[CMake] Idea - Modules development and management

[Michael Jackson]

On Dec 7, 2009, at 3:37 PM, Eric Noulard wrote:

> 2009/12/7 Nicholas Yue <yue.nicholas at gmail.com>:
>> Hi,
>>
>>   Does it make sense to separate out the development and deployment  
>> of
>> "Modules" in CMake?
>
> This kind of idea have already been raised on the ML.
> May be you should dig the ML archive in order to collect past ideas
> in order to see past pro- and cons- the main idea.
>
>>   I see an advantage because Modules update are more frequent as more
>> packages are added compare to the release cycle of CMake itself.
>>
>>   Maybe there is an easier way? Environment variable to point to an  
>> updated
>> Module path (note : I am referring to a complete Module including  
>> everything
>> that was originally ship with a given version of CMake, plus updates)
>
> I think you could already do that now.
> If you
> SET(CMAKE_MODULE_PATH /your/prefered/path)
> in your CMakeLists.txt
>
> then CMake will look in there first.
>
>
> -- 
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org


Just thinking out loud .. What if CMake had a "built-in" facility to  
check a common internet location for new/updated modules like a lot of  
programs do now-and-days. This (in my mind) would allow for the  
deployment of "Official" CMake modules (or at least those signed off  
by kitware) to be updated at a more rapid pace than CMake itself. The  
first iteration could just be a "check a website" type of deal. The  
next iteration would be something akin to a scheduled update type of  
thing. Again, some one would have to find the time to implement such a  
feature, plus setup the infrastructure internet stuff and all that,  
but might be very worthwhile in the long run.

_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio