> I think choosing the string LINUX would be A Bad Thing because
> we would really like this standard to be adopted by other UNIXen
> and that'll be a harder sell if we embed LINUX in the name. Something
> more OS-neutral is needed IMHO.
>
> I'd hate to have to write code that said:
>
> #if defined(GL_LINUX_ABI_VERSION_1_0)||
> defined(GL_BSD_ABI_VERSION_1_0) || \
> defined(GL_IRIX_ABI_VERSION_1_0) ||
> defined(GL_SOLARIS_ABI_VERSION_1_0) || \
> defined(GL_BEOS_ABI_VERSION_1_0) ||
> defined(GL_MACOS_ABI_VERSION_1_0)
> #include <GL/glext.h>
> #endif
Agreed, but I thought this was a LINUX ABI, not intended for other OS's?
The cleanest way to resolve this so it never comes back is to include
glext.h in gl.h, bite the bullet and port whatever code breaks. (ducks for
cover)
If we want glext.h to become a cross-platform thing, then we need a
cross-platform symbol. On this much we agree.
> I'd be happy to go with that - autoconf makes that kind of
> thing very easy
> and autoconf is what 95% of Linux programs use....but we are trying to
> compromise with Mark's position in order to get on with our
> lives here.
Forcing everyone to use autoconf is a much more heavy-handed solution than
my proposal that you add a symbol to your existing makefiles to prevent
automatic inclusion of glext.h, wouldn't you agree? I'm not knocking
autoconf by any means, but I don't think it should be a factor in this
discussion.
> I understand that - but if the issue is a tiny one (which
> this is) then
> we can save perhaps a year in finally getting rid of
> non-compliant systems
> by accepting XFree 4 as compliant. (I presume this is the
> only thing on
> which it would fail - right?)
>
> If this was a BIG issue (like how glGetProcAddress works or
> something) then
> I'd agree that we have to get it utterly right before
> committing - but the
> choice of a name for a token that most of us don't even want
> to use...I don't
> think that's worth an extra year (maybe) of lingering incompatibility.
I would urge you to resist the temptation to sweep this under the rug. This
is a long term problem if we don't solve it right, and solve it now.
Automatic inclusion of glext.h may cause a few people some short term pain,
but not inventing a reliable means to determine if glext.h can or should be
explicitly included will cause build problems from here until forever. If
this were such a trivial issue, we wouldn't still be talking about it.
There are two viable options IMO.
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).
