On Mon, 2013-09-30 at 16:56 -0500, Alexander von Gluck wrote: > On Mon, 2013-09-30 at 21:28 +0200, Ingo Weinhold wrote: > > On 09/30/2013 07:58 PM, Alexander von Gluck IV wrote: > > > In theory if > > > some company wanted to make their own binary OpenGL blob for us, they > > > would > > > simply create an OpenGL add-on. The Mesa dispatch code in our libGL.so > > > would > > > be more than happy to dispatch non-Mesa code (there is nothing in the Mesa > > > GL dispatch code that would require it to dispatch a Mesa add-on) > > > > I don't know about the OpenGL kit or Mesa internals. What I see, > > however, is this: There is an external project Mesa. There is an > > external project GLU. The Haiku build system did merges libglapi from > > Mesa and libGLU from GLU *unchanged* into a library libGL (*). This is > > just convoluted, particularly since GLU actually depends on libGL. > > Let me cover this once more. Ok, after looking through the BuildFeatures I get why you want a mesa and mesa_devel now. Pretty much you have the static mesa libraries and headers in mesa_devel, and nothing in mesa. mesa_devel is then used while compiling the system The thing is, those really don't need to exist in a place end users can install them though. I don't see any valid use cases for users to be statically linking core Mesa libraries into their projects. Is there any way we can flag packages as "private" or for build purposes only? -- Alex