<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Could then Aras Pranckevicius's talloc port to windows be merged into<br> > glsl2 branch before glsl2 is merged into master?<br> <br> </div>I think we learned our lesson with GLEW. Trying to keep a copy of an<br> external dependency in our tree only leads to sadness. I have no<br> intention to repeat that mistake.<br> I suspect there may also be some issue with including a piece of<br> software with such a different license in our tree. I'm not a lawyer,<br> so I may be unnecessarily paranoid here. *shrug*<br></blockquote><div><br></div><div>Another option I was considering (mostly for my own needs; I need to use GLSL2 fork in a closed source product) is a from-scratch implementation of talloc that keeps the same interface. Similar to what Mono folks have did with glib (they wrote their own eglib that matched the license and was much smaller in the result).</div> <div><br></div><div>In my case, talloc's LGPL is quite a hassle because I have to build talloc dlls/dylibs, which complicates deployment & packaging, etc.</div><div><br></div><div>I had not time to do that yet and probably won't have in the next month or two though :(</div> <div><br></div><div>talloc is not very large, looks like just taking one .h and .c file is enough. And then there are quite a few functions that GLSL2 does not ever use.</div></div><br clear="all"><br>-- <br>Aras Pranckevičius<br> work: <a href="http://unity3d.com">http://unity3d.com</a><br>home: <a href="http://aras-p.info">http://aras-p.info</a><br> <div><br></div>