[Mesa-dev] talloc (Was: Merge criteria for glsl2 branch)

[José Fonseca]

On Fri, 2010-08-13 at 02:03 -0700, Dave Airlie wrote:
> On Fri, Aug 13, 2010 at 4:58 PM, Aras Pranckevicius <aras at unity3d.com> wrote:
> >> > But I perceive talloc as different from all above: it's very low level
> >> > and low weight library, providing very basic functionality, and upstream
> >> > never showed interest for Windows portability. I'd really prefer to see
> >> > the talloc source bundled (and only compiled on windows), as a quick way
> >> > to have glsl2 merged without causing windows build failures.
> >>
> >> This seems like a reasonable compromise.  Is this something that you and
> >> / or Aras can tackle?  I don't have a Windows build system set up, so I
> >> wouldn't be able to test any build system changes that I made.
> >
> > Ok, looks like how/if to bundle talloc is still a very open question. In the
> > meantime, here's talloc 2.0.1 made to compile (and possibly work!) with
> > Visual C++ 2008 (Windows) and Xcode/gcc4.0 (Mac).
> > I've attached the modified talloc.c & talloc.h and the patch from original
> > talloc 2.0.1 (from here http://samba.org/ftp/talloc/). Caveat emptor: I only
> > verified this to work on my own GLSL2 fork, which does not compile in GLSL2
> > preprocessor, only the compiler & optimizer.
> > Like I said before, "full port" of talloc seems to be not needed for
> > compiling on Visual C++; just drop in talloc.h & talloc.c into the project
> > and that's it. Same for Mac with Xcode. It also seems that GLSL2 does not
> > use full talloc's functionality, and at least half of the implementation
> > could be dropped without anyone noticing. Just a note for if/when anyone
> > would try to re-implement talloc with Mesa's license.
> 
> Be careful about LGPLv3 rules,
> 
> If you are distributing anything linked with an LGPL library without
> accompanying source you need to dynamically link it,
>
> So for example a Windows driver or non open compiler, you can't just
> drop the LGPLv3 c+h files into the project, you need to create a
> dynamic library.

Yep. I got excited with v3's 
 http://www.gnu.org/licenses/lgpl.html section 5, "combined libraries",
but rereading it I found the requirement to use shared library (or ship
the object files for the closed source bits) is still there in section 4
d) 1).

I think this pretty much settles on my mind that we need a BSD
reimplementation of this in the medium term, as the hassle of changing
all the installer and code signing code to install/sign a new dll would
by far exceed the effort necessary to implement the functionality of
talloc missing from its muse, halloc.

Jose