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

[Oliver McFadden]

On Wed, Sep 05, 2012 at 08:11:55AM -0600, Brian Paul wrote:
> On 09/05/2012 03:38 AM, Oliver McFadden wrote:
> > 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.
> 
> I'd do it in a few chunks/patches at least (to aid in bisection if 
> needed.)

Agree.

> 
> Whether you do it file-by-file or FEATURE-by-FEATURE is up to you.  Be 
> careful with the FEATURE_remap_table flag too, I think that one's a 
> little tricky.

OK, thanks for the warning. I will do it FEATURE-by-FEATURE,
file-by-file shouldn't be how Git is used, and anyway I'd probably still
have to do FEATURE-by-FEATURE within those files...

-- 
Oliver McFadden.