mesa3d-dev

Re: [Mesa3d-dev] Use of "private" in glcore.h?

[Stephen J B. <sj...@li...>]

On Wed, 29 Nov 2000, Bret Mogilefsky wrote:

> On Wed, Nov 29, 2000 at 09:49:15PM -0700, Brian Paul wrote:
> > glcore.h is unmodified from the SGI SI.  It basically defines the
> > public interface to the OpenGL core.  I'm planning to make Mesa
> > use it in the future.
> > 
> > I guess we could add an #ifdef __c_plus_plus__ (or whatever) and
> > change the names to something else.  So much for pristine sources...
 
#define private foo
#include "glcore.h"
#undef private

????

----
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] Use of "private" in glcore.h?

[Bret M. <mog...@ge...>]

On Wed, Nov 29, 2000 at 09:49:15PM -0700, Brian Paul wrote:
> glcore.h is unmodified from the SGI SI.  It basically defines the
> public interface to the OpenGL core.  I'm planning to make Mesa
> use it in the future.
> 
> I guess we could add an #ifdef __c_plus_plus__ (or whatever) and
> change the names to something else.  So much for pristine sources...

Well, extern "C" can be wrapped around the #include by C++ source... but
there's no way to change the private keyword cleanly in just that place if
you expect clients to be using that struct member.  May I suggest the name
change to privateData (which is what I'm using in my local version)?

Bret
-- 
Bret Mogilefsky  ** mo...@ge... **  Programmer

Re: [Mesa3d-dev] Use of "private" in glcore.h?

[Brian P. <br...@va...>]

Bret Mogilefsky wrote:
> 
> Hi there.  I'm writing a driver for Mesa and I'd like to be able to use C++
> for large parts of it.  I notice that glcore.h has two structures with
> members named "private", which is a keyword in C++.  Aside from this, I can
> include everything without a problem.  I realize this is the CVS version,
> so perhaps this simply hasn't been addressed yet, but is anyone planning to
> rename those members to make it easier on C++ slobs like me?

glcore.h is unmodified from the SGI SI.  It basically defines the
public interface to the OpenGL core.  I'm planning to make Mesa
use it in the future.

I guess we could add an #ifdef __c_plus_plus__ (or whatever) and
change the names to something else.  So much for pristine sources...

-Brian

Re: [Mesa3d-dev] Use of "private" in glcore.h?

[Bret M. <mog...@ge...>]

On Wed, Nov 29, 2000 at 05:29:01PM -0800, Allen Akin wrote:
> I happen to like C++ myself, but depending on the OS you have in mind
> I might not recommend it for a driver.  For instance, until gcc 3.0
> comes along, there's no guarantee of binary compatibility for
> successive versions of C++ object files.  Compiler-generated
> references to libstdc++ (among other things) have caused compatibility
> problems under Linux in the past.

This is not for Linux, but for an embedded architecture where we have
control over the compiler, and have good support for optimization in C++;
I'm not too worried about binary compatibilities. =)

Bret
-- 
Bret Mogilefsky  ** mo...@ge... **  Programmer

[Mesa3d-dev] typedefs for asm code

[Gareth H. <ga...@va...>]

I've been doing a whole bunch of work on things like optimized lighting,
VB rendering, texture image conversion and so on.  Instead of going
through the nightmare of manually working out the offsets for the
various structures used, I wrote a little app that takes definitions
from mtypes.h etc and convertes them into byte offsets.  It outputs a
header file which can be included by all the asm files.  Very similar to
what Glide does for its asm code.

The way I'm handling this at the moment is a bit of a hack -- I've
added 	"GENERATED_SOURCES = X86/asm_types.h" to Make-config where
appropriate, and included the following rule in src/Makefile.X11:

X86/asm_types.h: types.h vb.h X86/gen_types.c
	$(CC) -I. -I$(INCDIR) $(CFLAGS) X86/gen_types.c -o X86/gen_types
	./X86/gen_types > X86/asm_types.h
	rm -f X86/gen_types

I then added GENERATED_SOURCES before OBJECTS when building the library:

$(LIBDIR)/$(GL_LIB): $(GENERATED_SOURCES) $(OBJECTS)
	$(MAKELIB) $(GL_LIB) $(GL_MAJOR) $(GL_MINOR) $(GL_TINY) $(OBJECTS)
	rm -f $(LIBDIR)/$(GL_LIB)*
	mv $(GL_LIB)* $(LIBDIR)

Hey, it works ;-)

This is certainly not the cleanest way to handle generated files,
especially when they depend on other source files and can't be generated
from scripts (easily, anyway).  I'm assuming it will be much easier to
do this with an autoconf build system.

A couple of questions then:

  - Does anyone have a better way of handling this for the old-style
    Makefiles?
  - My plan was to just include gen_types.c in CVS and generate
    asm_types.h as needed.  Is this the best idea?  Should the DRI copy
    of Mesa have asm_types.h, or should it generate it as well?
  - Anyone have strong objections to committing it as it stands now?

-- Gareth

Re: [Mesa3d-dev] Use of "private" in glcore.h?

[Allen A. <ak...@po...>]

On Wed, Nov 29, 2000 at 04:30:07PM -0800, Bret Mogilefsky wrote:
| Hi there.  I'm writing a driver for Mesa and I'd like to be able to use C++
| for large parts of it.

I happen to like C++ myself, but depending on the OS you have in mind
I might not recommend it for a driver.  For instance, until gcc 3.0
comes along, there's no guarantee of binary compatibility for
successive versions of C++ object files.  Compiler-generated
references to libstdc++ (among other things) have caused compatibility
problems under Linux in the past.

Allen

[Mesa3d-dev] Use of "private" in glcore.h?

[Bret M. <mog...@ge...>]

Hi there.  I'm writing a driver for Mesa and I'd like to be able to use C++
for large parts of it.  I notice that glcore.h has two structures with
members named "private", which is a keyword in C++.  Aside from this, I can
include everything without a problem.  I realize this is the CVS version,
so perhaps this simply hasn't been addressed yet, but is anyone planning to
rename those members to make it easier on C++ slobs like me?

Thanks,
Bret
-- 
Bret Mogilefsky ** mo...@ge... ** Programmer

Re: [ogl-sample] Re: [Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Stephen J B. <sj...@li...>]

On Mon, 27 Nov 2000, Sven Goethel wrote:

> Aehem, well, but how about splitting the Mesa distribution from:
> 	MesaLib & MesaDemos
> to:
> 	MesaLib & (MesaSGIGLU || MesaGLU) & MesaDemos
> 
> where, of course, the MesaSGIGLU is preferred ..
 
If there are going to be ugly issues with which C++ runtime library
SGI-GLU pulls-in/requires then I think it's vital from an application
support perspective to minimise the number of varients there can
be out there.  I would not want to see (say) Debian and RedHat shipping
the SGI version of GLU with SuSE and Corel shipping GLU-classic.

I'd also oppose splitting GLU off from Mesa's main download because
that will result in lots of end-users installing "Mesa" and yet having
no valid GLU implementation because they failed to download/install it.

Supporting OpenGL applications under Linux is hard enough as it is -
look at the mail archives for an active OpenGL application (TuxRacer
for example) and you'll see that at least 95% of the posts are OpenGL
installation problems of one kind or another.  That consumes an insane
amount of people's time - PLEASE, let's not make it any harder.

IMHO, 99% of widely distributed OpenGL apps for Linux will not be
using the problematic functions in GLU-classic - because those programs
were almost certainly developed using that library and either don't use
the broken functions or have work-arounds that work OK. Hence most
existing applications will get no benefit from SGI-GLU.  In any case,
the kinds of applications that need things like tesselators and spline
patches tend not to be games - more often they are things like scientific
visualisers and custom applications which are not widely circulated.

Hence, I suggest that until the g++ standard library stuff settles
A
down, we avoid making SGI-GLU the default.  I think the Mesa documentation
should point out that we *WILL* make the transition - but not yet - and
advise people who experience problems with GLU-classic to switch over
immediately.  Meanwhile I think we should continue to ship GLU-classic
by default.

---
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Brian P. <br...@va...>]

Sven Goethel wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 27 November 2000 17:44, Brian Paul wrote:
> > Olivier Michel wrote:
> > > Sven Goethel wrote:
> > > > Thanxs a lot !
> > > >
> > > > How about integrating the SGI GLU Sources to the Mesa distribution ?
> > > > Did you asked Brian ?
> > >
> > > Yes. Brian told me that he would like to see this SGI GLU integrated
> > > into Mesa in a forthcoming version of Mesa, but I cannot tell you when.
> >
> > I haven't started that work either, yet.
> >
> > > There may be problems with mixing different licenses into a single
> > > package... (SGI OSS license is different from Mesa LGPL, don't ask me
> > > where!).
> >
> > The main Mesa library is not LGPL, it's copyrighted XFree86-style.
> > There are some other components in the Mesa distro such as GLUT, GLU
> > and some drivers which have other copyrights.  It's explained in
> > the docs.
> >
> > The SI GLU copyright is compatible with XFree86 so there should be
> > no problem including the sources with Mesa.  The concern I have is
> > what to do for people who do not have a C++ compiler.  If they
> > can't compile the SI GLU they'll either need to use the old Mesa
> > GLU or find a precompiled library for their system.  And until
> > they solve that, they can't run many of the Mesa demos, etc.
> >
> > -Brian
> 
> Aehem, well, but how about splitting the Mesa distribution from:
>         MesaLib & MesaDemos
> to:
>         MesaLib & (MesaSGIGLU || MesaGLU) & MesaDemos
> 
> where, of course, the MesaSGIGLU is preferred ..

Yes, I might do that.



> another Q: why do you revert the MesaGLU to GLU 1.1 ?

Because there were a few severe bugs in the (unfinished) 1.2
tessellator implementation.

-Brian

Re: [Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Sven G. <sgo...@ja...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 November 2000 17:44, Brian Paul wrote:
> Olivier Michel wrote:
> > Sven Goethel wrote:
> > > Thanxs a lot !
> > >
> > > How about integrating the SGI GLU Sources to the Mesa distribution ?
> > > Did you asked Brian ?
> >
> > Yes. Brian told me that he would like to see this SGI GLU integrated
> > into Mesa in a forthcoming version of Mesa, but I cannot tell you when.
>
> I haven't started that work either, yet.
>
> > There may be problems with mixing different licenses into a single
> > package... (SGI OSS license is different from Mesa LGPL, don't ask me
> > where!).
>
> The main Mesa library is not LGPL, it's copyrighted XFree86-style.
> There are some other components in the Mesa distro such as GLUT, GLU
> and some drivers which have other copyrights.  It's explained in
> the docs.
>
> The SI GLU copyright is compatible with XFree86 so there should be
> no problem including the sources with Mesa.  The concern I have is
> what to do for people who do not have a C++ compiler.  If they
> can't compile the SI GLU they'll either need to use the old Mesa
> GLU or find a precompiled library for their system.  And until
> they solve that, they can't run many of the Mesa demos, etc.
>
> -Brian

Aehem, well, but how about splitting the Mesa distribution from:
	MesaLib & MesaDemos
to:
	MesaLib & (MesaSGIGLU || MesaGLU) & MesaDemos

where, of course, the MesaSGIGLU is preferred ..

just an idea.

another Q: why do you revert the MesaGLU to GLU 1.1 ?

kind regards, sven
- -- 
mailto:sgo...@ja...
www   : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
voice : +49-521-2399440, +49-170-2115963; fax: +49-521-2399442
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6IuL4HdOA30NoFAARAtQ1AJ4oLroYFigJWYLOplMXk2dQaejbLQCgj9C1
kdzzSQDAx4+AdF7onEIFcIA=
=Yju6
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Jean-Francois P. <pan...@di...>]

> 
> The SI GLU copyright is compatible with XFree86 so there should be
> no problem including the sources with Mesa.  The concern I have is
> what to do for people who do not have a C++ compiler.  If they
> can't compile the SI GLU they'll either need to use the old Mesa
> GLU or find a precompiled library for their system.  And until
> they solve that, they can't run many of the Mesa demos, etc.
> 

And given the state of flux of the C++ ABI and runtime libraries
under Linux, I'm personally not too fond of C++-compiled system libraries
right now. For instance, the SGI GLU included with the SGI ProPack 1.3
overlay has a runtime dependency on /usr/lib/libstdc++-libc6.1-1.so.2
(ouch). If you need to compile a program with a newer version of
g++ (for instance one of the 2.97 snapshots which installs its
own libstdc++ in /usr/local/lib)  where both the runtime
library and the ABI are incompatible, you are likely to run into
problems. I have no idea how this g++ ABI transition is going to be
handled...

JF

Re: [Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Brian P. <br...@va...>]

Olivier Michel wrote:
> 
> Sven Goethel wrote:
> 
> > Thanxs a lot !
> >
> > How about integrating the SGI GLU Sources to the Mesa distribution ?
> > Did you asked Brian ?
> 
> Yes. Brian told me that he would like to see this SGI GLU integrated
> into Mesa in a forthcoming version of Mesa, but I cannot tell you when.

I haven't started that work either, yet.


> There may be problems with mixing different licenses into a single
> package... (SGI OSS license is different from Mesa LGPL, don't ask me
> where!).

The main Mesa library is not LGPL, it's copyrighted XFree86-style.
There are some other components in the Mesa distro such as GLUT, GLU
and some drivers which have other copyrights.  It's explained in
the docs.

The SI GLU copyright is compatible with XFree86 so there should be
no problem including the sources with Mesa.  The concern I have is
what to do for people who do not have a C++ compiler.  If they
can't compile the SI GLU they'll either need to use the old Mesa
GLU or find a precompiled library for their system.  And until
they solve that, they can't run many of the Mesa demos, etc.

-Brian

[Mesa3d-dev] Re: Thanxs for SGI's GLU 1.3 libs !

[Olivier M. <Oli...@cy...>]

Sven Goethel wrote:

> Thanxs a lot !
>
> How about integrating the SGI GLU Sources to the Mesa distribution ?
> Did you asked Brian ?

Yes. Brian told me that he would like to see this SGI GLU integrated
into Mesa in a forthcoming version of Mesa, but I cannot tell you when.
There may be problems with mixing different licenses into a single
package... (SGI OSS license is different from Mesa LGPL, don't ask me
where!).

> The current GLU 1.1 Version is very useless
> - - as Brian stated also on his Mesa site !
>
> Yours, Sven
> - --
> mailto:sgo...@ja...

-Olivier

[Mesa3d-dev] Commit

[Keith W. <ke...@va...>]

I've just committed a biggish change which includes a few different items:

- Swappable t&l modules.  Drivers can turn off the standard 'tnl'
module and replace its dispatch hooks with functions of their own.
There are functions provided to wake the tnl module up again and
recalculate all its internal state.

An example of this is included in FX/fxvtxfmt.c which accelerates
similar states to the fastpath, but via the glVertex interface.  In
addition, it also calculates lighting by one or more infinite lights.

The FX code is somewhat buggy, and is disabled by default.  It
exists as a testbed for ideas rather than a necessarily permanent 
piece of the FX driver.  It is quicker in isosurf by 50% or so, but
the tdfx-3-0-0 code might be quicker still, though for different
reasons.

To avoid the requirement for such drivers to implement the entire set
of allowable entrypoints in Begin/End objects, I've implemented a set
of non-core functions (like glColor3s, glVertex2iv, etc) which simply
translate their arguments to more common types (typically floats) and
call the equivalent entrypoint in that type.  For example:

static void
loopback_Color3b( GLbyte red, GLbyte green, GLbyte blue )
{
   GLubyte col[4];
   col[0] = BYTE_TO_UBYTE(red);
   col[1] = BYTE_TO_UBYTE(green);
   col[2] = BYTE_TO_UBYTE(blue);
   col[3] = 255;
   glColor4ubv(col);
}

This allows drivers to concentrate on the core set of entrypoints,
which are listed in a struct "GLvertexformat" in dd.h.


- Cleanup of tnl module functions which decompose complex operations
like 'glRectf' or 'glDrawArrays' into Begin/Vertex/End commands.
These always had issues with compilation into display lists because it
was difficult to preserve the OUTSIDE_BEGIN_END requirement, and
dealing with this led to various bugs.  

I've introduced a new internal entrypoint '_tnl_hard_begin' which will
preserve the check for OUTSIDE_BEGIN_END when compiled.  I've also
improved the tracking of begin/end state through display list
compilation, so we are able to tell whether the list has settled down
to a known state, and hence whether the check can be executed at
compile time instead.

As a result of this, calling Rectf should now have no overhead
compared to calling the corresponding begin/vert/end commands
directly, and those vertices can co-exist in a VB with vertices from
normal operations or other rects.  


- Renamed all tnl functions to start with _tnl_, some math functions
to start with _math_.


Keith

Re: [Mesa3d-dev] Mesa3d's CVS log messages

[Brian P. <br...@va...>]

Alan Hourihane wrote:
> 
> On Wed, Nov 22, 2000 at 08:33:43AM -0700, Brian Paul wrote:
> > Alan Hourihane wrote:
> > >
> > > On Wed, Nov 22, 2000 at 08:25:39AM -0700, Brian Paul wrote:
> > > > Alan Hourihane wrote:
> > > > >
> > > > > Any chance of using DRI's new cvs log messages on Mesa ?
> > > >
> > > > That would be great.  Are you volunteering?  Feel free to do so.
> > > >
> > > I don't have CVS write access to Mesa. Otherwise I would.
> >
> > You do now. :)
> >
> Mmmm, (egg of face). O.k. will do, It seems that I still can't check out
> the necessary stuff because of lack of permissions to CVSROOT/history.
> 
> I'll wait a little while then try again.

User privilege changes sometimes take a few hours to go into effect.

-Brian

Re: [Mesa3d-dev] Mesa3d's CVS log messages

[Alan H. <aho...@va...>]

On Wed, Nov 22, 2000 at 08:33:43AM -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> > 
> > On Wed, Nov 22, 2000 at 08:25:39AM -0700, Brian Paul wrote:
> > > Alan Hourihane wrote:
> > > >
> > > > Any chance of using DRI's new cvs log messages on Mesa ?
> > >
> > > That would be great.  Are you volunteering?  Feel free to do so.
> > >
> > I don't have CVS write access to Mesa. Otherwise I would.
> 
> You do now. :)
> 
Mmmm, (egg of face). O.k. will do, It seems that I still can't check out
the necessary stuff because of lack of permissions to CVSROOT/history.

I'll wait a little while then try again.

Alan.

Re: [Mesa3d-dev] Small speed improvement

[Brian P. <br...@va...>]

Klaus Niederkrueger wrote:
> 
> Again I bore you with an idea to improve the software-rasterizer. This however should be relatively easy implemented (though the speed gain should only be minor, too). It is even so simple that I wonder if I'm getting something wrong:
> 
> In 'src/swrast/s_span.c' there is e.g. the function 'gl_write_texture_span', which in turn calls first
>         gl_texture_pixels( ctx, 0, n, s, t, u, lambda, rgba, rgba );
> and
>         _mesa_fog_rgba_pixels( ctx, n, fog, rgba );
> and afterwards it does
>         gl_scissor_span( ctx, n, x, y, mask )
> and
>         _mesa_depth_test_span( ctx, n, x, y, z, mask );
> 
> So if one of the last two functions (there are some other like stipple, alpha etc.), decides that no pixel is visible, then nothing is drawn and a 'return' is used.
> 
> Would changing the order of the first two functions and the rest have any negative effect? In the special case above, this would prevent the calculation of the whole texturing and fog stuff, which in the end is not drawn anyway.

Between texture application and the depth test there are a few other pixel
operations, namely the alpha test and stencil, which if done out of order,
could cause invalid rendering.

But in most cases you're right.  If only depth testing and texturing are enabled,
depth testing could be done first and potentially reduce the number of texture
lookups, etc.


> As a second step (that requires some more changes) you could also use the 'mask' array to calculate the fog and the texturing only at points that are not being masked, which could give some more speed up, when you use depth and such.
> 
> As always, I don't have time to do the changes myself, but maybe someone wants to try it out.

I don't have time to try it either.

-Brian

Re: [Mesa3d-dev] Mesa3d's CVS log messages

[Brian P. <br...@va...>]

Alan Hourihane wrote:
> 
> On Wed, Nov 22, 2000 at 08:25:39AM -0700, Brian Paul wrote:
> > Alan Hourihane wrote:
> > >
> > > Any chance of using DRI's new cvs log messages on Mesa ?
> >
> > That would be great.  Are you volunteering?  Feel free to do so.
> >
> I don't have CVS write access to Mesa. Otherwise I would.

You do now. :)

-Brian

Re: [Mesa3d-dev] Mesa3d's CVS log messages

[Alan H. <aho...@va...>]

On Wed, Nov 22, 2000 at 08:25:39AM -0700, Brian Paul wrote:
> Alan Hourihane wrote:
> > 
> > Any chance of using DRI's new cvs log messages on Mesa ?
> 
> That would be great.  Are you volunteering?  Feel free to do so.
> 
I don't have CVS write access to Mesa. Otherwise I would.

Alan.

Re: [Mesa3d-dev] Mesa3d's CVS log messages

[Brian P. <br...@va...>]

Alan Hourihane wrote:
> 
> Any chance of using DRI's new cvs log messages on Mesa ?

That would be great.  Are you volunteering?  Feel free to do so.

-Brian

[Mesa3d-dev] Small speed improvement

[Klaus N. <kl...@ma...>]

Again I bore you with an idea to improve the software-rasterizer. This however should be relatively easy implemented (though the speed gain should only be minor, too). It is even so simple that I wonder if I'm getting something wrong:

In 'src/swrast/s_span.c' there is e.g. the function 'gl_write_texture_span', which in turn calls first 
	gl_texture_pixels( ctx, 0, n, s, t, u, lambda, rgba, rgba );
and
	_mesa_fog_rgba_pixels( ctx, n, fog, rgba );
and afterwards it does
	gl_scissor_span( ctx, n, x, y, mask )
and
	_mesa_depth_test_span( ctx, n, x, y, z, mask );

So if one of the last two functions (there are some other like stipple, alpha etc.), decides that no pixel is visible, then nothing is drawn and a 'return' is used.

Would changing the order of the first two functions and the rest have any negative effect? In the special case above, this would prevent the calculation of the whole texturing and fog stuff, which in the end is not drawn anyway.

As a second step (that requires some more changes) you could also use the 'mask' array to calculate the fog and the texturing only at points that are not being masked, which could give some more speed up, when you use depth and such.

As always, I don't have time to do the changes myself, but maybe someone wants to try it out.

Greetings

	Klaus

[Mesa3d-dev] Mesa3d's CVS log messages

[Alan H. <aho...@va...>]

Any chance of using DRI's new cvs log messages on Mesa ?

Alan.

[Mesa3d-dev] Re: tgmath.h

[Jon T. <jt...@lu...>]

You guys wrote:

>> > Update of /cvsroot/mesa3d/Mesa/src/math
>> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20778
>> > Modified Files:
>> m_matrix.c
>> Log Message:
>> removed #include <tgmath.h>
> 
> I`ve never heard of it - maybe something John added?

	Yeah that was me.  I was having weird libc problems for a while last 
weekend, and that extra #include helped me build at one point.  I never 
heard of <tgmath.h> either before then |->.

Jon

[Mesa3d-dev] Re: [Mesa3d-cvs] 'Mesa/src/math m_matrix.c'

[Keith W. <ke...@va...>]

br...@us... wrote:
> 
> Update of /cvsroot/mesa3d/Mesa/src/math
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv20778
> 
> Modified Files:
>         m_matrix.c
> Log Message:
> removed #include <tgmath.h>

I've never heard of it - maybe something John added?

Keith

Re: [Mesa3d-dev] tgmath.h

[Brian P. <br...@va...>]

"Jacob (=Jouk) Jansen" wrote:
> 
> Hi All,
> 
> what is tgmath.h. It is not available on my VMS-box. Leaving it out seems
> to work. Is VMS the only system lacking this include file?

It looks like an imaginary math library header.  Removing it didn't
seem to effect anything.

Keith, if this is significant, please add it back in glheader.h
surrounded by #ifdef __linux__/#endif, or similar.


> P.S. I changed on my system all occurences of "types.h" to "mesa_types.h".
>  If Brian says this change is OK I'll check them in this afternoon (MET)
>  Otherwise if I hear no objections I'll check them in wednesday morning (MET)
>  (tomorrow I'll be off-line)

I think I'd prefer mtypes.h since we already have mmath.h for the
same reason (and it's shorter).

-Brian