<div class="gmail_quote">On Mon, Feb 16, 2009 at 4:36 PM, Alexander Neundorf <span dir="ltr"><<a href="mailto:a.neundorf-work@gmx.net" target="_blank">a.neundorf-work@gmx.net</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>
> Since many of the dependencies overlap, is there general interest in this<br>
> 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<br>
> neutral site like SF.net or Google Code) where the ports could be stored,<br>
> baselined, etc. and then released so that anyone could download whichever<br>
> are needed and incorporate them into their own projects? Export/Install<br>
<br>
</div><br>You suggest to keep a whole copy of these projects there, not only the build<br>
files, right ?<br>
A problem is how to keep this current, i.e. they will more or less quickly<br>
become out-of-date (happened to me with python).</blockquote><div><br>I think the entire release would be CM'd along with the CMakeLists.txt. One way to do this would be via a tarball + patch stored within CM (to make baselining easier). If this approach was adopted then on a release you could untar + apply patch and zip it up.<br>
<br>You would have to have volunteers who would subscribe to each project's announce mailing list and on a release examine the diff for new/old files or anything of interest and tweak the CMakeLists.txt files.<br><br>
Honestly, I don't think it would be that much work provided it's done properly. Obviously there would have to be criteria for new projects being added to the repository. Here are a few ideas (not set in stone by any means), just random thoughts popping out of my head. =)<br>
<br>1.) The library would need to have a volunteer to rebase it<br>2.) The library would need to be binary ABI stable or have a volunteer willing to handle DLL filename versioning<br>3.) Ideally the library would have little or no dependencies<br>
</div></div><br>-- <br>Philip Lowman<br>