[Mesa-dev] [PATCH 2/2] intel: add ANGLE_texture_compression_dxt extension support.

[Oliver McFadden]

On Tue, Sep 04, 2012 at 12:41:12PM -0600, Brian Paul wrote:
> On 09/04/2012 12:08 PM, Ian Romanick wrote:
> > On 09/04/2012 08:16 AM, Brian Paul wrote:
> 
> 
> >> Most of the patch is 'FEATURE_x' changes. I've been tempted to rip out
> >> all that stuff.
> >>
> >> The original idea was to make it easy for people to build smaller Mesa
> >> subsets (and the ES subset) by running the code through the
> >> preprocessor
> >> with all the FEATURE_x flags set on/off as needed. In the past some
> >> people were really concerned about code size for static analysis and to
> >> minimize binary sizes. I haven't heard any concerns about that in a
> >> long time. If someone's really determined to make a tighter subset,
> >> they'd have to go above and beyond turning off FEATURE_x flags anyway.
> >>
> >> And now, we're building one library that supports runtime selection of
> >> full OpenGL profiles, core profiles and ES profiles. The FEATURE stuff
> >> doesn't add any value for that and seems more trouble than it's worth.
> >>
> >> Any other opinions?
> >
> > I'm not a fan of the fine-grained FEATURE_x bits. If we had just a
> > couple (like FEATURE_ES2) that were actually maintained, I could see
> > the potential for value. As it is, I think it just adds maintenance
> > burden.
> 
> OK. Any volunteers to start removing the FEATURE_x lines?

If nobody else wants to take this work, I'll do it. I suspect most if it
could be done with unifdef (or sed) and possible white-space cleanup
afterwards.

Would you prefer one big "nuke all FEATURE_* defines" patch, or
individual patches "remove FEATURE_a define", "remove FEATURE_b define",
etc. (Obviously excluding the useful ones, _GL, _ES1, _ES2.)

It doesn't make much difference to the amount of work for me.

-- 
Oliver McFadden.