Danny Backx escreveu: > On Sun, 2007-08-05 at 16:08 +0100, Pedro Alves wrote: >> Danny Backx wrote: >>> Actually I did several modifications to try to follow the GNU coding >>> standards. That is what you're referring to, isn't it? >>> >>> Please tell me where exactly do I not follow one now ? I'll fix. >>> >> Bummer, this really makes me sound a nitpicker. I would have preferred >> you hadn't committed the new patch without posting it to the list first. >> I had more comments. > > Don't worry about it. > >> See here for reference: >> http://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting > > I did read much of that document. But it's easy to miss on part of it if > there's so many, and so detailed, rules. > >> Please move the attribute implementation into either arm.c, or better >> yet, reuse the SUBTARGET_ATTRIBUTE_TABLE mechanism already implemented >> for the "selectany" attribute. Since this is a target specific >> attribute it has no place in the common c code. > > Looking into this. > >> Same comment about the formatting of the comment. Just look at the other >> comments in the file or other files. I find that the comment about >> duplicating >> code adds no value. > > Frankly this way the amount of comment in the ChangeLog gets so small > that it becomes almost useless. But that does appear to be the way they > do it. Oh well... > >> At this point, and since you will have to move code around, perhaps it would >> be better to revert the patch in full, and then post the new version here, >> and then apply in all at once again when it's OK. > > Why would I want to do that ? This is a version tracking mechanism, > right ? What's the problem with having intermediate versions in there ? >
To have a patch == changeset == 'atomic feature' available. If I want to find out what broke what, I remove one patch. If a feature gets scattered over several commits it gets harder to isolate. It is specially important in toolchain development, where finding out what broke who is particularly difficult. That is a mindset one gets used to when developing with the other GNU tools guys. And for the reviewer it is better too. I would prefer to review a patch against the previous state, than against something which shouldn't have been installed in the first place. Oh well, its just two of us, and I hate to be always saying no... Cheers, Pedro Alves ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
