I've now landed the new code formatting via astyle, and reindented the
codebase. Tags have been laid down immediately before and after for
easy reference. One of the biggest commits I've ever made :)
% bzr diff -rREINDENT_2014_PRE..REINDENT_2014_POST | wc
66688 277256 1970223
Even gzip'd the diff is over 360k, so I may have to buy new floppies
to hold it...
This adds a 'make indent' target to the Makefile to run it over the
codebase. Of course you need Artistic Style[0] installed to run it.
astyle seems pretty good about doing things right the first time, so
if I run 'make indent' now, the result is no changes. astyle also
seems pretty good about not messing with things other than what we've
defined in its control file. There are lots of little bits of
formatting it leaves alone as a result, so if we make minor cleanups
in such places[1] astyle won't mess with it one way or another.
The goal is for running this to be a standard part of the workflow, so
that we keep things in consistent style. So don't be afraid to run
'make indent' arbitrarily often, especially before commits.
It's fairly easy to verify with md5 that this didn't change the
generated code. Running md5 over the .o files after compilation
before/after yields no changes except in otp.o, and those are just the
result of line numbers changing in assert()'s. To verify, I ran
% make CMAKE_EXTRAS='-DCMAKE_C_FLAGS="-O2 -DNDEBUG"' allclean all
% md5 build/CMakeFiles/ctwm.dir/*.o
both before and after the merge; with -DNDEBUG to undef away the
asserts, there are no diffs between the md5's before and after the
commit. This technique could be useful below.
------------------------------------------
DEALING WITH OUTSTANDING BRANCHES
An unpleasant bit about wholesale rewrites like this is dealing with
people's outstanding changes. There's not much we can directly do
with just diffs, but it can be dealt with fairly easily for
outstanding _branches_ (and for diffs, the way would be to _make_ a
branch and do it that way).
The following instructions should in concept be Correct(tm) from my
thinking about the matter, and testing aggres.
0) If your branch predates the cmake conversion, probably want to deal
with merging up through that (r304) first, just to worry about one
thing at a time. Do whatever testing/etc is necessary making it
all work right for you there before moving on to dealing with the
indentation.
1) Bring your branch up to date with right before the reindent was
run:
% bzr merge -rREINDENT_2014_PRE $trunk
Resolve conflicts and test as necessary and commit. You now have
the formatting config and such ready, but the code isn't any
different from any other changes in trunk to date.
2) Reindent your branch.
% make indent
If you don't have Artistic Style installed, you'll need it. If
that's impractical, well, you'll probably need to get somebody to
help you do the conversion; publish your branch as of (1) above and
somebody can do the rest for you.
It may be worth a compile and quick test, but this should leave the
code as it was before. You can do tests via MD5 as discussed
above. Commit this.
3) Merge trunk post-indent.
% bzr merge -rREINDENT_2014_POST $trunk
This will bring up a fair number of conflicts. But because you
already resolved things correctly (presumably) in (1), they should
all be spurious; just the result of both sides modifying almost
every line. So you just want to tell it to go ahead and talk your
side of each conflict.
% bzr resolve --take-this
If you run 'bzr status' now, it should show the pending merge tip
for the reindent rev from trunk, but no file changes at all.
That's good; that means it worked right! Go ahead and commit that.
4) Now you're past the reindent! If trunk has moved ahead
significantly since that indent you might as well go ahead and do a
full mergeup now, but otherwise things should now be working just
like normal going forward.
Hopefully all our lives will be a little more pleasant going forward.
You may hate the style, but at least from now on you'll hate a SINGLE
style :)
[0] http://astyle.sourceforge.net/
[1] e.g., the prototypes at the top of list.c which have logs of space
between the return type and the function name; if we collapse
those down to single spaces, or add a dozen more, astyle might
change the way continuation lines are indented, but will leave the
spaces we set alone.
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
