Re: [GtkGLExt] API changes for the next major gtkglext release (glext)

[Braden McDaniel <braden endoframe com>]

On 1/11/10 2:55 PM, Arc Riley wrote:
> On Mon, Jan 11, 2010 at 7:32 AM, Mukund Sivaraman <muks banu com
> <mailto:muks banu com>> wrote:
>
>     We cannot combine code that has a similar license to the BSD license
>     (non-copyleft), with LGPL licensed (copyleft) code.
>
>     You can link in between these, such as a program linking to a library,
>     but not form a single binary object from it, such as a .so containing
>     both LGPL and BSD licensed code.
>
>     I'm not a lawyer. This is our interpretation of these licenses, and
>     what we'll stick with.
>
>
> You are incorrect in your understanding of copyright law.

This branch of the discussion is moot; technical issues, rather than 
legal ones, are driving this decision.

> GLEW is broken /now/.  It has apparently been fixed in it's development
> tree, which will not be available to us for 6-12 months after their next
> release due to the various distribution release cycles.

I can understand why that could be inconvenient for you; but this is not 
the sort of problem that should be addressed by adding functionality to 
GtkGLExt.

> Our next
> release is due in 38 days, and as such, GLEW is completely unavailable
> to us.  gtkglglext.h is ready and works now, it's been widely packaged
> and distributed, and that is what we are using.

Then be aware that the current plan is for this to go away in the next 
release.

> We do not like dependency bloat nor does the Gnome project.

I would be very surprised if persons within the Gnome project working to 
reduce the proliferation of dependencies view the application of NIH 
principles as a correct strategy for achieving that goal.  (But if they 
do, then I don't mind working against them.)

> Gnome has
> far too many dependencies as it is and there is an active, collective
> push to keep this number from expanding any further.  Removing vital
> functionality from a library, which on whole only adds a few K to the
> compiled .so (vs a few hundred K in a separate .so), because another
> library outside the Gnome project provides it's functionality is not
> acceptable.

That's not convincing: where the importance of this issue overrides 
other considerations, link statically.

Putting arbitrary GL-related functionality into GtkGLExt is precisely 
what we're moving away from in the next release.  The glext stuff is 
getting the axe because GTK+ applications don't have any special needs 
in this department (i.e., ones that aren't shared by non-GTK+ 
cross-platform apps).  IMO, if there is a convincing argument to be made 
here, it's one that refutes that claim.

Braden