[ 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).
It seems to be, based on Brian's post, that the con to including glext.h
automatically is not a big issue in practice because the old extension entry
points are still available in the DSO. Therefore a legacy app has two
choices:
1) Do nothing and continue to compile/link, because the extension are still
available
Pros:
- nothing to do, it still works
Cons:
- not portable between implementations because its not ported to
GetProcAddress
- see below*
2) Port to oglbase
Pros:
- portability
Cons:
- requires additional effort
* I know one more issue, but the window of opportunity for failure is
becoming increasingly small. If an app was written to use an extension
which was not available on Linux, it wouldn't have attempted to use it on
Linux. But with a new all-encompassing glext.h, it may now try to use this
extension and have link errors. Our exposure is now limited to apps which
use the extensions which were not available on Linux/Mesa but were on other
platforms.
If we can agree that automatic inclusion of glext.h is the _simplest_
solution, modulo this legacy app issue, then we must decide, if the legacy
problem is diminishingly small, what is our threshold of pain? To what
extremes do we wish to go in order to ensure that NO code or makefiles must
be modified to compile under the new ABI? I agree that we should not ignore
the issue entirely, Steve has convinced me of that, so the threshold of pain
must have a limit, but I also think that limit must be higher than zero. We
have an opportunity to do this right, do it now, and avoid this from ever
coming back, and avoid polluting all future GL code with Linux-specific
turds. (Windows-specific turds are bad enough - APIENTRY anyone? Lets not
compound the problem.)
Most legacy apps will continue to compile/link just fine because of the
measures Brian took to ensure this. Only a few will have any issue at all,
and they can be fixed by adding a single define to a makefile if the author
_really_ doesn't want to port to oglbase.
Lets just do it and get it behind us. Small short term pain, Big long term
gain.
-- Michael
