> From: Thomas Roell [mailto:[EMAIL PROTECTED]]
>
> I think that is not suffient to break the tie. But there is another
> intresting observation. A lot of people voted 2A for tactical reasons,
> but would really loved to have voted for 2B. I would now be intrested
> why the 2C voters think that having a -DGL_INCLUDE_NO_EXTENSIONS type
> define is preferrable over a -DGL_INCLUDE_EXTENSIONS type
> define. Looking throu all the discussions I only found two type of
> comments, that it really makes sence to include glext.h automatically,
> and that a define is needed for for somehow enabling/disabling the
> inclusion. There were also comments regarding breaking source
> compatibility by uncoditionally including glext.h (or including it by
> default). As within a normal jury, I would like to hear more arguments
> that it makes sence to go via 2C.
I'm the one who first proposed this vote off-line, and I originally proposed
that we only vote on options (b) and (c), since they both addressed the
compatibility concerns. The only question in my mind was who should
shoulder the burden of defining a symbol in their makefile: legacy apps or
all future apps. It seems to me that we want the cleanest solution fot the
future, since I am operating under the assumption that we have only seen the
tip of the iceberg so far in terms of linux/opengl support. Given that we
want all future development to use oglbase, lets make that the default
behavior, and provide an easy switch for backward compatibility for anyone
who needs to recompile a legacy app. Note that many legacy apps will work
just fine w/o defining the switch, and legacy binaries are unaffected.
Therefore the ONLY window of exposure we have is legacy apps which (a) want
to be recompiled, (b) don't care about oglbase compliance, AND (c) were
coded on other platforms to use extensions which are not available in
today's linux implementations. That seems like a relatively small window!
The burden we place on that developer for resisting oglbase compliance is
that he defines one symbol in his makefile to avoid including glext.h. Note
that all three of those conditions must be met before the developer even
need to lift a finger to edit their makefile. I don't see this as a burden
worth optimizing for, and it makes it cleaner for all future development.
We have an opportunity to do this cleanly, and I wish we would take it.
Having thus stated my preference for (c), let me add that I still find (b)
to be more acceptable than (a). Option (a) is very undesireable to me since
I don't want people to be required to explicitly include glext.h, and it
lacks the advantage you suggested that static prototypes be removed via
ifdef when compiling for oglbase. Options (b) and (c) address both of these
concerns, as well as the compatibility concerns raised by you and Steve.
-- Michael
