[haiku-development] Re: OpenGL System hpkg's
- From: Alexander von Gluck <kallisti5@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 30 Sep 2013 22:29:57 -0500
On Tue, 2013-10-01 at 04:59 +0200, Ingo Weinhold wrote:
> On 09/30/2013 11:56 PM, 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:
> > * A static dispatch library from Mesa
> > (glapiLibrary) which is libglapi.a
> > While this static dispatch library comes from Mesa, it is *not*
> > Mesa centric. It implements glapi which is the interface between
> > opengl clients and the opengl renderer.
> >
> > The static dispatch library (from glapi) is *not* Mesa only. It can
> > dispatch and launch any kind of OpenGL renderer. The calls in and
> > out of glapi are standardized. This is why we have the same code in
> > our OpenGL kit for GCC2 (mesa 7.8.2) and GCC4 (mesa 9.1.1).
> >
> > libGL.so *is* our OpenGL kit and doesn't contain just Mesa code.
>
> I'm not so much interested in what is considered the OpenGL kit or how
> the libraries or the packages are called. What I am concerned with is
> that ATM we have three separate sets of code (Mesa, GLU, and the code in
> the Haiku repository) which seem to cyclically depend on each other.
I really don't see how they are cyclical. (besides the linking libGLU
into libGL mess, that was Be's fault though and we can't change it
unless we break BeOS compat)
libGL.so depends on Haiku API wrappers and Mesa dispatch code
The add-ons depend on Mesa
That is all pretty simple and direct.
> This is, to say it diplomatically, inelegant. It makes building
> inconvenient. And by merging in code from a third party project which
> progresses independently, we'll potentially run into versioning
> problems, which we wouldn't, if we kept things cleanly separated with
> properly versioned libraries.
>
> So my question is: how can we reorganize things in a clean way? Note
> that we are not bound by how they were organized in BeOS. We can freely
> break up and shuffle code and libraries, as long as we keep a symlink
> /system/lib/libGL.so in our GCC 2 build that points to a library that --
> directly or indirectly -- provides all the required symbols.
I've been moving as much code rendering code into Mesa as I can, however
we *have* to wrap calls at a lower level as openGL initialization isn't
a universal process per platform and Be's api differs from Linux,
Windows, and OS X (which also all differ)
Originally I was working towards moving llvm into the Mesa package, but
at this point I am reconsidering given what PM changes. (Likely I'll
revert to using a llvm_devel package, and was looking into that this
evening)
So the clean way is:
haiku-kit-opengl
build depends on mesa_devel (Mesa matching primary build platform)
haiku-kit-opengl-devel
build depends on mesa_devel
haiku-kit-opengl-swrast
* build depends on mesa_devel (Mesa 7.8.2)
haiku-kit-opengl-swrast-legacy
* build depends on mesa_devel (Mesa 9.1.1+)
This is how things work, keep in mind that gcc2 is frozen at Mesa 7.8.2.
gcc2 will *never* compile anything newer. (and Mesa doesn't want gcc2
patches, I asked. We can't even patch the latest code for gcc2 as the
patches would pretty much re-write all of Mesa)
> > This is why I think calling our OpenGL kit "mesa" would be confusing. We
> > could call the add-ons mesa, however that still wouldn't be accurate as
> > they aren't *just* mesa code.
> >
> > If applications required OpenGL, they would simply need to require
> > "haiku-kit-opengl". No application should require "mesa" as we don't
> > have a virign "mesa" in Haiku.
>
> That isn't how it works anyway. We generally don't declare dependencies
> at the package level. Instead, packages provide resolvables, and other
> packages require those resolvables. This way we are free to reorganize
> packages (split them up, merge them, replace them).
Fair enough, haiku-kit-opengl provides libGL. libglu provides libGLU.
-- Alex
Other related posts:
