Michael Gold wrote:
>
> [ Warning: what follows is a pre-coffee post ]
>
> Oops, sent that before I was finished.
>
> 1) include extension defs or glext.h in gl.h everywhere (except windows)
> Pros:
> - nobody ever has to decide whether or not to include it
> - new code is portable to other OS's
> Cons:
> - legacy code or makefiles will require minor mods, a short term problem
>
> 2) add a symbol, any symbol, which promises that glext.h exists
> Pros:
> - apps that want extensions on Linux can reliably include this header
> - new code is portable to other OS's
> Cons:
> - apps that want extensions on Linux must include this header
> - the problem of whether or not to include glext.h on other platforms
> remains unsolved
>
> 3) sweep it under the rug
> Pros:
> - we stop arguing about this
> Cons:
> - confusion ensues
> - people cannot code which is portable between OS's
>
> I vote for (1).
> ...
I'm with you, Michael. Have gl.h include glext.h.
I believe all that's left is Steve's concerns about bringing apps to
Linux, recompiling, and dying because of libGL.so not containing some
extension functions.
To address that Steve, if you know of some extensions for which this
might happen, let me know what they are and I'll put stubs for those
functions in libGL.so ASAP. I suspect this list would include some SGI
extensions which Mesa never implemented. This should help minimize
problems.
-Brian
