No, I'm not disagreeing with you because I'm confused or belligerent. I'm disagreeing with you because I think you're wrong, and I'm allowed to do that. Sorting includes is not the issue here, the spacing is. The hang up seems to be making life easier for the script, and while I sympathize I am not willing to add one more silly detail I have to worry about when I'm writing code just to make a single script happy. I already proposed a way to write the script that should preserve the spacing several emails ago. Use spaces and changes between types of files as markers for groups of includes in the file, group includes by type, sort them, and insert them at the markers without disturbing the spacing around them. If that doesn't do it then do what you want, because I'm tired of talking about this too.
And why shouldn't I "care about this so much" that I'm willing to write a couple of emails defending my opinion? Is it the case that I have to believe people's lives are at stake before I decide not to tacitly accept something? My suggestions have been dismissed pretty regularly in the last few days, and this one I feel strongly enough about to argue. Gabe nathan binkert wrote: >> I mean that it's not implied that there's exactly one blank line which >> his script enforces. If there are two lines, one is deleted. I would >> claim that the fact that there are blank lines at all could be looked at >> as a way to make the comments stand out in the particular text on the >> wiki, although in many circumstances it would be good to have the spacing. >> > > Is there a particular reason that you care about this so much or are > you simply bikeshedding? Do you oppose sorted includes? This is a > pretty common concept and makes it much easier to find an include > among many when you're hacking on a file. (My script found a number > of duplicates). If you're not opposed to sorting, do you not find it > nice to have a script that fixes include ordering across the entire > source tree? I like it because if you do something simple like rename > a file or a directory (which I have done), then you can just do a > regex search/replace, run the script and fix it up. I've done this > sort of thing many times and I've gotten pretty fed up with the fact > that I had to manually fix the diff afterwards. This particular one > was bad enough that I went through the trouble to write a script to > fix it. > > The reason for enforcing spaces is two-fold. First, it makes things > look better and easier to follow if the groups are separated by a > single blank line. In general, you'll find that in the M5 source > tree, we do not have multiple blank lines in files intentionally. The > second reason is that it's just a pragmatic issue of writing the > script. If someone inserted a random spacing between three groups of > includes and some of the files move, where do the spaces go? This is > not even trivial to answer and is certainly more difficult to code. > My script does not affect whitespace before or after the #includes, > and does not try to do anything when includes are separated by any non > #include line except for sort them as independent groups. (i.e. it > doesn't mess around by rearranging where an #ifdef is) > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
