[CMake] open source project for CMake ports?

Philip Lowman philip at yhbt.com
Wed Feb 18 01:11:33 EST 2009


On Tue, Feb 17, 2009 at 4:19 PM, Eric Noulard <eric.noulard at gmail.com>wrote:

> 2009/2/17 Eric Noulard <eric.noulard at gmail.com>:
> > 2009/2/17 Alexander Neundorf <a.neundorf-work at gmx.net>:
> >>>
> >>> But a http://autoconf-archive.cryp.to/ type archive for CMake modules
> >>> would also be a good idea.
> >>
> >> At FOSDEM we also discussed about something like this, some kind of
> >> semi-official place where to get additional cmake files.
> >> Right now you can look in several places, KDE being one of them.
> >>
> >> One idea was to actually ship those files as "unsupported" with cmake,
> but in
> >> a directory which is not searched by cmake by default, so that if
> somebody
> >> wants to use a file from this directory, he has to do something manually
> >> (either copy the file somwhere or set CMAKE_MODULE_PATH) to use it.
> >
> > You may find conflict when trying to bundle the file.
> > Since CMake CVS seems to be able to file(DOWNLOAD
> > then only shipping convenient macros that is able to
> > [conditionnally] and selectively download "unsupported" macros files
> would
> > be "better" because:
> >
> > 1) CMake bundler won't have to choose which "unsupported" cmake macros
> >    to bundle
> >
> > 2) One can get up-to-date "unsupported" macro without waiting for next
> CMake
> >     release
> >
> > I would go for a macro whose signature may be
> >
> >
> > get_additionnal_cmake_scripts(URL LOCALFILENAME FORCE_UPDATE)
> >
>
> Sorry too fast keyboard hit...
>
>  which would may be usable like this:
>
>  get_additionnal_cmake_scripts(
> http://websvn.kde.org/trunk/KDE/kdeutils/cmake/modules/FindLibZip.cmake
>
> ${PROJECT_SOURCE_DIR}/cmake/FindLibZip.cmake
>                                                               NO )
>
> if FORCE_UPDATE is YES/TRUE then the module would be updated everytime
> cmake is run.
> The default would be not to update if the file is already there locally.
>
> So then CMake may indicates a list of base url where "unsupported"
> scripts may be found
>
> cmake --help-unsupported-modules
>

This is an interesting idea.

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).

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.

Just a thought.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090218/2a31acb3/attachment.htm>


More information about the CMake mailing list