From: Mike A. H. <mh...@re...> - 2001-06-05 04:28:37
|
I'm having some trouble with Mesa that I'm not sure how to properly handle and would like some advice. For all of our XFree86 4.x releases, we have shipped XFree86 but have replaced the Mesa that comes with it with the standalone Mesa from the mesa3d project hacked to support DRI. The reason for this is that we need software OpenGL working on both 4.x and 3.3.6, and DRI hardware acceleration on 4.x. This 'hack' works well, however it is somewhat of a maintenance nightmare, because portions of the DRI code that are needed must be extracted from our XFree86 sources first then included in the separate Mesa packaging. Every time XFree needs updating, the Mesa package thus needs updating as well to keep them in sync. There were some oddball chicken and egg dependancy problems with this solution, and so we've decided instead of having a separate Mesa package, to take the Mesa package and fold it into the XFree86 src.rpm. I've got this part working now. Mesa builds first, and then X, but when it comes %install time in the specfile, the two Mesa's step on each others toes and I'm not sure how to work around it other than intense gross hacks - that are likely to be a maintenance nightmare in their own regards. Currently the relevant portions of the XFree spec look like: %install mkdir -p $RPM_BUILD_ROOT{/usr/{include,lib},/etc/{pam.d,security/console.apps}} make DESTDIR=$RPM_BUILD_ROOT install install.man -C xc # FIXME: Can MESA stuff be disabled with Imake instead? # Clean out Mesa stuff { rm -f $RPM_BUILD_ROOT/usr/include/GL find $RPM_BUILD_ROOT/usr/lib -type f |grep -vi "glide"|xargs rm -f rm -rf $RPM_BUILD_ROOT/usr/X11R6/include/GL rm -f $RPM_BUILD_ROOT/usr/X11R6/lib/lib{GL,OSM}* } As such, I'd like to have opinions on how to solve this dilemna from those who actually understand how Mesa works - I am no OpenGL guy by far. Here is what would IMHO be the best - at least from my viewpoint as a distributor/package maintainer: The easiest method (for me) would be if the Mesa that comes with XFree86 had the 3.3.6 compatibility built right into it, and was perhaps an Imake directive to enable at X build time (BuildMesaSupport336?). This would make our hack unnecessary, and would make package maintenance much simpler as well. I'd much rather spend my time hacking on and contributing to XFree86 itself than on packaging nightmares in unfamiliar turf... ;o) Alternative to that, the second method would be if in XFree86 there were Imake directives HasMesa, UseMesa like with Freetype2, and friends, and I could stop libGL, libOSMesa, etc from being built, and from being installed in my buildroot. That would remove the need for that hack we have now that deletes these libraries during the buildroot'd install phase in the src.rpm. Another possibility would be for us to redo the Mesa stuff and instead of patching standalone Mesa with parts of DRI from X, if we were to patch Mesa in X with parts of the standalone Mesa. Not something I am comfortable with attempting myself though. There are likely other approaches also that would work, but as I've just started with Mesa stuff, I have no idea what is realistic from what I've said above, and what is not. How difficult would it be for someone familiar with the Mesa and X code to merge the needed bits for 3.3.6 support into XFree86 sources? Thanks in advance for any suggestions/comments/flames or help with this matter. TTYL ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, Red Hat Inc. Ontario, Canada, P6C 5B3 http://www.redhat.com Phone: (705)949-2136 ---------------------------------------------------------------------- Latest XFree86 test RPMS: ftp://people.redhat.com/mharris/testing |