On Fri, 24 Mar 2000, Michael Gold wrote:
> > 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?
It is a Linux ABI- but that doesn't mean that we have to actively dissuade
other OS's from picking it up and using it as-is. Certainly the BSD guys
will want it. Almost all Linux software ends up being ported to BSD
at some stage - and there is no reason to make that harder than it has
to be IMHO.
> 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)
Aaaarrrgggghhhhhh!!!!!
> If we want glext.h to become a cross-platform thing, then we need a
> cross-platform symbol. On this much we agree.
Yes.
> > 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.
So I'll give in on that one and let Mark have his symbol.
*ANYTHING* to avoid breaking all those existing programs.
> 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
No it isn't - you still have to test a symbol in order to use
extensions with glGetProcAddress...it's only the lines:
#ifdef <our magic symbol>
#include <glext.h>
#endif
...that you are really saving...and in amongst all the other
#ifdef WIN32
#include <windows.h>
#else
#include <unistd.h>
#endif
...stuff, that's really a minor thing.
> Cons:
> - legacy code or makefiles will require minor mods, a short term problem
...a short term problem for a LOT of people - and an ongoing low-level
problem forever.
I don't think we should be here quite deliberately and knowingly
screwing up hundreds upon hundreds of people when there is a perfectly
viable alternative. That's quite indefensible IMHO.
> 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
Don't forget:
- existing legal OpenGL programs continue to work unmodified
> Cons:
> - apps that want extensions on Linux must include this header
No, that's not true - application authors still have a choice:
* They can continue to code the way they do now and remain
portable to other platforms - although (as now), apps will
need to be recompiled for each Linux machine since they are
not using the ABI. They can still use locally compiled-in
extensions. This is OK for programs distributed in source
code form (which is still the vast proportion of OpenGL
programs under Linux).
* Or they can opt to go the oglbase route.
Remember that we are explicitly NOT telling OpenGL implementations
to remove local extension definitions from gl.h
> - the problem of whether or not to include glext.h on other platforms
> remains unsolved
Why is that a problem? If the 'magic symbol' is not defined in gl.h
(which it won't be on other platforms that don't provide glext.h)
then programs won't attempt to include glext.h and all will be well
on other platforms. Whether they choose to use oglbase on their
platform is a matter for those other OpenGL implementations.
> 3) sweep it under the rug
> Pros:
> - we stop arguing about this
> Cons:
> - confusion ensues
> - people cannot code which is portable between OS's
Agreed.
> I vote for (1).
I really can't tolerate (1) - it has to be (2) for me.
Steve Baker (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
