On 12/03/2013 01:00 AM, Rogovin, Kevin wrote: > Hi, > > I appreciate the feedback, however I am having difficulty in figuring out a > -good- way to break up the first patch. The basic beans is that all of it's > parts are needed together for it to even make sense. To be precise, the > changes consist of: > 1) implementation of linked list of #extension directives > (glcpp_extras.[ch] ) > 2) addition to glsl_parser_extras.cpp (and .h) using it > 3) changes to glcpp-parse.y and glcpp-lex.l, checking for the new field and > using it. > > Until it is active (i.e. the changes in glsl_parser_extras.cpp passing it to > the glcpp), all the code > added is more or less dead code; in particular if the patch is broken up, the > patch that turned it > on would appear to be the guilty party but when in fact it was a previous > patch. > > What is a good way to break up the patch so that the code added is not dead > and so that > finding a bug in the added code can be done on a patch by patch basis? > > Best Regards > -Kevin Rogovin
Yeah...there's a point where you switch from the old code to the new code, and most bugs would probably bisect to that. In this case, I think that's fairly unavoidable. However, splitting it up into multiple patches would definitely make it a lot easier to review. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
