[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)
jfonseca at vmware.com
Wed Aug 11 16:45:58 PDT 2010
On Wed, 2010-08-11 at 13:18 -0700, Aras Pranckevicius wrote:
> > Could then Aras Pranckevicius's talloc port to windows be
> merged into
> > glsl2 branch before glsl2 is merged into master?
> I think we learned our lesson with GLEW. Trying to keep a
> copy of an
> external dependency in our tree only leads to sadness. I have
> intention to repeat that mistake.
> I suspect there may also be some issue with including a piece of
> software with such a different license in our tree. I'm not a
> so I may be unnecessarily paranoid here. *shrug*
> 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).
That's a good idea. Jakob was also considering adding the missing bits
to http://swapped.cc/halloc/ to make it compatible with talloc at source
> In my case, talloc's LGPL is quite a hassle because I have to build
> talloc dlls/dylibs, which complicates deployment & packaging, etc.
> I had not time to do that yet and probably won't have in the next
> month or two though :(
> 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.
I really can't condone the glsl2 branch merge until we have some
consensus on how the talloc dependency should be handled, windows or
More information about the mesa-dev