Commit graph

18 commits

Author SHA1 Message Date
jlam
13b9a4eeef version.mk no longer defines MESA_VERSION. Put the version number of the
required package in its place.  Thanks to Jan Schaumann for diagnosing the
problem.
2004-01-25 17:26:07 +00:00
adam
ba0b56c0ff Mesa-6.0 packages now use LIBTOOL and finally build 2004-01-22 12:58:07 +00:00
salo
f4cfbd40fe Remove references to non-existent files.
From Soren Jacobsen via PR pkg/23537.
2003-11-23 07:22:10 +00:00
jschauma
b949499421 Update Mesa and friends to latest version 5.0.2:
- fixed texgen problem causing texcoord's Q to be zero (stex3d)
- default GL_TEXTURE_COMPARE_MODE_ARB was wrong
- GL_CURRENT_MATRIX_NV query was wrong
- GL_CURRENT_MATRIX_STACK_DEPTH_NV query was off by one
- GL_LIST_MODE query wasn't correct
- GL_FOG_COORDINATE_SOURCE_EXT query wasn't supported
- GL_SECONDARY_COLOR_ARRAY_SIZE_EXT query returned wrong value
- blended, wide lines didn't always work correctly
- glVertexAttrib4svNV w component was always 1
- fixed bug in GL_IBM_rasterpos_clip (missing return)
- GL_DEPTH_TEXTURE_MODE = GL_ALPHA didn't work correctly
- a few Solaris compilation fixes
- fixed glClear() problem for DRI drivers (non-existant stencil, etc)
- fixed int/REAL mixup in GLU NURBS curve evaluator (Eric Cazeaux)
- fixed delete [] bug in SI GLU (bug 721765) (Diego Santa Cruz)
- glFog() didn't clamp fog colors
- fixed bad float/int conversion for GL_TEXTURE_PRIORITY in the
  gl[Get]TexParameteri[v] functions
  - fixed invalid memory references in glTexGen functions (bug 781602)
  - integer-valued color arrays weren't handled correctly
- glDrawPixels(GL_DEPTH_COMPONENT) with glPixelZoom didn't work
- GL_EXT_texture_lod_bias is part of 1.4, overlooked in 5.0.1
- build GLUT with -fexceptions so C++ apps propogate exceptions

While here, fix PR pkg/23003 by moving the version number to version.mk
and including that in the buildlink.
2003-09-29 21:30:28 +00:00
jschauma
aa0aa518ac Finally remove support of Mesa 3.4.1 completely as discussed at length
on tech-pkg@ at various times.  This means that regardless of what kind of
GL support comes with X11, if a package depends on GL, Mesa 5.0.1 (or higher)
will be installed into ${LOCALBASE}.

Some troubleshooting after the latest patches by Krister Walfridsson.
2003-08-26 01:43:48 +00:00
jschauma
937d21f1b7 Hopefully finally get this right:
Default Mesa Version should be 3.4.2, so that people who don't care and have
GL in XF don't need to build the whole thing.  If MESA_REQD is set to 5.0.1
(as, for example, by MesaDemos), require version 5.0.1 of MesaLib, gl* etc.

If libGL.so.5 is found to be present on the system, force MESA_REQD to be
5.0.1 to avoid accidental downgrades if MESA_REQD was not specified before-
hand.

Changes reviewed by tron@ (thanks!).
2003-07-15 23:31:21 +00:00
jschauma
0ecb99ecd8 If MESA_REQD is not set, but we detect a 5.x library, set MESA_REQD to
the current default of 5.0.1 (rather than 5.0) so that distinfo remains
correct.
2003-07-07 02:05:59 +00:00
jschauma
6ce68eec3a Oops, put check for MESA_REQD below where it will be set definitely if unset
before.
2003-07-03 18:47:41 +00:00
jschauma
81e95fd3a9 If MESA_REQD is not set to 5.x and we find libGL.so.5, set MESA_REQD to
5.0.

If MESA_REQD is set to 5.x, pass -DGLX_GLXEXT_LEGACY to CPPFLAGS, to avoid
breakage if a package looks for glx_ext.h.
2003-07-03 18:27:29 +00:00
jschauma
795177db77 Fix PR pkg/20685 by changing the if-statements to allow creation of a fake
package for clean-depends-list purposes.
While here, also remove the no longer necessary CFLAGS after previous commit
in MesaLib and also add distinfo for MesaLib for non Mesa-5.0.
2003-03-24 18:07:07 +00:00
tron
8ba42278c5 Create fake libtool archives to fix build problems on XFree86 4.x system
when programs are supposed to be linked with the included Mesa libraries.
These changes by Johnny C. Lam fix PR pkg/20649 by myself.
2003-03-13 07:01:01 +00:00
jschauma
12c7eda41d Update Mesa and friends to version 5.0, using patches provided in PR pkg/19302.
At the same time, move Mesa and friends to LOCALBASE rather than X11BASE, so
that they can be installed regardless of XF version.  Introduce MESA_REQD variable
that can be set to 5.0, thus allowing systems with XF4 to indicate that the
provided version is not good enough.

All packages using Mesa, MesaLib, glu or glut will get a PKGREVISION bump
over the next few days.
2003-03-09 19:04:52 +00:00
jlam
9377a2aeab Compute version of built-in Mesa without using "glxinfo", which is broken
when the capabilities of the running X11 server differ from the X11 server
on the system for which the package is meant.  We now try to guess the
Mesa version number based on which OpenGL specification is implemented.

Separate out the logic into its own file, Mesa/version.mk, and use it in
MesaLib's and glu's buildlink2.mk files.

Note that Mesa/version.mk should only be used by the Mesa packages and is
_not_ for general use.
2002-11-20 22:13:21 +00:00
tron
aaa4491f86 Don't try to run "glxinfo" outside a X11 session which would produce lots
of error message.
2002-11-19 09:19:36 +00:00
jlam
db3a779c2d Alter Mesa/GL packages so that they may always be installed if
X11PREFIX != X11BASE (xpkgwedge is installed).  Introduce a new variable
MESA_REQD that defaults to "3.4.2" and represents the version of Mesa/GL
needed by a package.  MESA_REQD is intended to be used by package Makefiles
or by buildlink2.mk files.

It should now be possible to update this package to the latest release
(5.0), and have it work on:

	* XF86-3.x with or without xpkgwedge
	* XF86-4.x with xpkgwedge
2002-11-18 07:49:24 +00:00
bouyer
7d38a52534 MesaLib is part of XFree 4 on solaris too. 2002-10-27 13:50:09 +00:00
tron
dc618de551 Fix problem with XFree86 checks under Solaris. 2002-09-01 11:49:42 +00:00
jlam
e2afa97f51 Merge changes in packages from the buildlink2 branch that have
buildlink2.mk files back into the main trunk.  This provides sufficient
buildlink2 infrastructure to start merging other packages from the
buildlink2 branch that have already been converted to use the buildlink2
framework.
2002-08-25 18:38:05 +00:00