<div class="gmail_quote">On Sun, Feb 15, 2009 at 11:30 PM, Bill Hoffman <span dir="ltr"><<a href="mailto:bill.hoffman@kitware.com">bill.hoffman@kitware.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;">
<div><div></div><div class="Wj3C7c">Philip Lowman wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
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?<br>
<br>
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.<br>
<br>
A tertiary goal would be convincing the 3rd party dependencies to switch to CMake for their native build systems.<br>
<br>
Does this sound interesting?<br>
<br>
</blockquote></div></div>
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...</blockquote>
<div><br>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.<br>
<br>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.<br>
</div></div><br>-- <br>Philip Lowman<br>