>Number:         23845
>Category:       pkg
>Synopsis:       pkgsrc lacks OpenGL flavour selection framework
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 22 19:27:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Michal Pasternak
>Release:        N/A
>Organization:
Good people with bad reputation
>Environment:
N/A
>Description:


        Currently pkgsrc applications link directly graphics/MesaLib. 


As libGL and libGLU are often provided by 3rd party vendors (eg. wip/XFree86-libs/, NVidia's binary drivers, propably some more -- ATI binary drivers for Linux(?), OpenGL on IRIX operating systems family) --  it would much be better to:

        link against the available, "3rd-party"-provided library, 

eventually giving the administrator to choose via setting a variable in /etc/mk.conf


The problem is serious if you use pkgsrc on a system, that provides hardware OpenGL rendering. MesaLib in pkgsrc can't autodetect hardware renderers; even if your kernel and XFree86 support the hardware rendering, they won't be used.


Mesa, that comes with XFree86 4.3.0 (wip/XFree86-libs), can autodetect hardware.


NVidia's GL library is closed-source, so I can't tell anything about it. Anyway, pkgsrc should have an option to include such kind of 3rd party libraries. They are available for FreeBSD and Linux, and that's not an audience you can ignore.


I never used IRIX system, so I can hardly test this, but it could work for it also.


We could either teach MesaLib to autodect rendering hardware -- or provide a system-wide, unified buildlink2.mk file, that would take care about OpenGL implementation selection.



        Here is my proposal: 

use system-wide mk/opengl.buildlink2.mk (just like pthread and ossaudio). 

Introduction of such file can be performed right now, because this won't break anything. Then, the packages should be converted to explictly include this file and not graphics/MesaLib/buildlink2.mk, as it is now.

Please download the file from:

   http://doc.safenet.pl/opengl.buildlink2.mk

and get the basic set of patches for currently available applications from:

   http://doc.safenet.pl/pkgsrc-opengl.diff

The .mk file is very basic now, but it's functionality could be extended later. And, what's most important, it should not break too much. It does not act exaclty like the "old" stuff for some packages -- it buildlinks libGL and libGLU always (I don't think this is a big problem), but in case someone wants to have the same behaviour, and complicate the things a bit, buildlinking in opengl.buildlink2.mk could be dependent on setting some variables in the Makefile.

I have currently built some packages -- using FreeBSD-4.9-STABLE and wip/XFree86 -- which include: graphics/glut, graphics/gle, audio/xmms, x11/xscreensaver, x11/qt3-libs (!) (read that as x11/kdelibs3 and x11/kdebase3). Everything works fine!

The most important test: graphics/MesaDemos - fails only on:
pointblast.o: In function `menu':
pointblast.o(.text+0x6c2): undefined reference to `glPointParameterfvARB'
pointblast.o(.text+0x70b): undefined reference to `glPointParameterfARB'
pointblast.o: In function `main':
pointblast.o(.text+0xc39): undefined reference to `glPointParameterfvARB'

and:
winpos.o: In function `init':
winpos.o(.text+0x826): undefined reference to `glWindowPos2fARB'


Other MesaDemos _work_ very good with wip/XFree86-libs provided libGL and libGLU. I suppose, that if I'd tweak a bit with XFree86-libs Makefiles, I don't have time for right now, I could get winpos and pointblast also to work. And anyway, this is _NOT_ an issue at all, because packages can _still_ use graphics/MesaLib by explictly defining USE_OPENGL_LIB=pkgsrc USE_OPENGL_GLU=pkgsrc in it's makefile. Big and important packages work without problems (possibly because they use a better known or wider available OpenGL functionality subset, than MesaDemos).

Everything else works fine and uses my hardware rendering equipment.

Mind that I have not tested this on other OS/hardware.

I am open for the discussion; feel free to ask me any questions on topic; if any of you, pkgsrc developers, finds it useful, please mind, that I am ready to spend my time to get this functionality working.

If you think, that this is totally unnecessary, please remember, that NetBSD will have DRI/DRM someday, so you will have to face this problem anyway, sooner or later.
>How-To-Repeat:
Obvious.
>Fix:
Discuss, patch, commit.
>Release-Note:
>Audit-Trail:
>Unformatted: