[CMake] open source project for CMake ports?

[Philip Lowman]

On Sun, Feb 15, 2009 at 11:30 PM, Bill Hoffman <bill.hoffman at kitware.com>wrote:

> Philip Lowman wrote:
>
>> Hi,
>>
>> Luigi suggested a kind of CMake ports system in a recent thread here on
>> the CMake mailing list.  This would presumably be a system whereby popular
>> 3rd party dependencies which have not yet CMakeified their source trees
>> could be CM'd and baselined in one place and ultimately downloaded for easy
>> incorporation into CMake projects (especially with a goal towards MSVC/MinGW
>> portability).  VTK seems to be doing this internally for several of it's
>> dependencies and the OSG project seems interested in doing the same for
>> similar reasons but would prefer not to duplicate a bunch of work.  Since
>> many of the dependencies overlap, is there general interest in this kind of
>> a thing from the VTK perspective or from others?
>>
>> The goal would be to create an open-source project (hosted probably at a
>> neutral site like SF.net or Google Code) where the ports could be stored,
>> baselined, etc. and then released so that anyone could download whichever
>> are needed and incorporate them into their own projects?  Export/Install
>> support could also be built into the projects so that they could be prebuilt
>> and installed by others and used that way as well.
>>
>> A tertiary goal would be convincing the 3rd party dependencies to switch
>> to CMake for their native build systems.
>>
>> Does this sound interesting?
>>
>>  I think it might be more interesting to start a campaign to push the
> cmake files into those projects.  Why shouldn't jpg,tiff,zlib, and friends
> not ship with good cmake files.  I guess if something like what you suggest
> was created, it might push the developers of those projects to accept the
> CMake files to avoid the partial fork in the project...


Part of me believes that even if they were to accept the CMake build systems
as submitted, in the long-term, patches would still have to be maintained
against their native CMake builds.  This is why I listed it as a secondary
goal.  Some of my concerns here are centered around library names (witness
Kitware's prefix of each library with "kw", I'm guessing for technical and
legal reasons?) and of course the eventual growth of the CMake build systems
by each open-source project for their own reasons (they may choose to
INSTALL() different targets, provide for unit testing, or any number of
things which could prove difficult to be kept "optional" to the original
CMakePorts build, especially if someone isn't watching their trunk).  The
goal is to be able to add a project to your build by simply saying
"add_subdirectory(CMakePorts/libjpeg)" or something like that.  In the end
it might be a completely different use case then what the developers of jpg,
tiff, zlib, and friends have in mind.

So ultimately I think this might have to be more of a long term endeavour.
Ultimately, at least if that ends up being the case it's a burden that many
people can share instead of each project doing individually.  Most of these
libraries are fairly stable and their release cycles are fairly long...  I
think.  In the end, tools could be developed to make the baselining process
easy (assuming diff isn't good enough).  Ultimately, it might turn a little
bit into Debian packaging, except for software building.  Obviously the
whole project would likely have a bias towards Windows since Linux doesn't
have the problem of not coming with these very useful libraries.

-- 
Philip Lowman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090216/3d0c1762/attachment-0001.htm>