<div class="gmail_quote">On Tue, Feb 17, 2009 at 4:19 PM, Eric Noulard <span dir="ltr"><<a href="mailto:eric.noulard@gmail.com">eric.noulard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/2/17 Eric Noulard <<a href="mailto:eric.noulard@gmail.com">eric.noulard@gmail.com</a>>:<br>
<div class="Ih2E3d">> 2009/2/17 Alexander Neundorf <<a href="mailto:a.neundorf-work@gmx.net">a.neundorf-work@gmx.net</a>>:<br>
>>><br>
>>> But a <a href="http://autoconf-archive.cryp.to/" target="_blank">http://autoconf-archive.cryp.to/</a> type archive for CMake modules<br>
>>> would also be a good idea.<br>
>><br>
>> At FOSDEM we also discussed about something like this, some kind of<br>
>> semi-official place where to get additional cmake files.<br>
>> Right now you can look in several places, KDE being one of them.<br>
>><br>
>> One idea was to actually ship those files as "unsupported" with cmake, but in<br>
>> a directory which is not searched by cmake by default, so that if somebody<br>
>> wants to use a file from this directory, he has to do something manually<br>
>> (either copy the file somwhere or set CMAKE_MODULE_PATH) to use it.<br>
><br>
> You may find conflict when trying to bundle the file.<br>
> Since CMake CVS seems to be able to file(DOWNLOAD<br>
> then only shipping convenient macros that is able to<br>
> [conditionnally] and selectively download "unsupported" macros files would<br>
> be "better" because:<br>
><br>
> 1) CMake bundler won't have to choose which "unsupported" cmake macros<br>
> to bundle<br>
><br>
> 2) One can get up-to-date "unsupported" macro without waiting for next CMake<br>
> release<br>
><br>
> I would go for a macro whose signature may be<br>
><br>
><br>
> get_additionnal_cmake_scripts(URL LOCALFILENAME FORCE_UPDATE)<br>
><br>
<br>
</div>Sorry too fast keyboard hit...<br>
<div class="Ih2E3d"><br>
which would may be usable like this:<br>
<br>
get_additionnal_cmake_scripts(<a href="http://websvn.kde.org/trunk/KDE/kdeutils/cmake/modules/FindLibZip.cmake" target="_blank">http://websvn.kde.org/trunk/KDE/kdeutils/cmake/modules/FindLibZip.cmake</a><br>
<br>
${PROJECT_SOURCE_DIR}/cmake/FindLibZip.cmake<br>
</div> NO )<br>
<br>
if FORCE_UPDATE is YES/TRUE then the module would be updated everytime<br>
cmake is run.<br>
The default would be not to update if the file is already there locally.<br>
<br>
So then CMake may indicates a list of base url where "unsupported"<br>
scripts may be found<br>
<br>
cmake --help-unsupported-modules<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>This is an interesting idea.<br><br>One thought I had was the potential of new features creeping into the CMake module you're downloading that aren't yet available in the CMake version that you're using. One example of this as of late is the HINTS feature. There are still many people out there using CMake 2.4.x and plenty of Find Modules which now support HINTS (which obviously doesn't work in 2.4.x).<br>
<br>My point is by pointing your source tree off to some URL you immediately assume that the module located there will ALWAYS work with the current trunk of your software (from now until the end of time) when this may not necessarily be the case.<br>
<br>Just a thought.<br></div></div><br>-- <br>Philip Lowman<br>