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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
