Re: GNU indent for C code

[Mark Wielaard]

Hi (Graydon see below why you are explicitly CCed),

On Sat, 2004-03-27 at 20:08, Etienne Gagnon wrote:
> Greg just told me that I am supposed to first send mail here, before
> committing code.

Yes, the rule is that all proposed patches should be send to this list
first. And in general it is seen as polite to wait a little while before
committing, even though you might think it is obviously correct, if the
change hasn't been discussed or mentioned before on this or the main
mailinglist.

> Mainly I did the following changes that I would mainly qualify of
> "cosmetic":
> 1- Fix some .cvsignore files, and remove a few leftover generated files.
> 2- Add autogen.sh for hackers (script that calls auto* tools).

Thanks. Could you also update the HACKING file with this info?
This would have been a nice one to wait a bit on. Not that it is really
controversial, but it took me and Michael/Patrik their autobuilder off
guard. Had we seen this on the list we could have investigated how to
update our build procedures before either CVS upping or giving an OK to
the change.

> 3- Add in Makefile.am an "indent" target that applies GNU Indent to all
>     .c & .h files below native/ .
> 4- Actually make indent.
> [...]
> 2004-03-27  Etienne M. Gagnon <address@hidden>

Little nitpick. It should be
[date] <two spaces> [full name] <two spaces> [email-contact]
Some tools depend on the two spaces between each item.
(Although there are more ChangeLog entries were this is wrong.)

> [...]
> 2004-03-27  Etienne M. Gagnon <address@hidden>
> 
>       * ...[a bunch of .c/.h files]...:
>          Indented using GNU indent.
> 
> If you think I made the biggest mistake on earth and should be assimilated
> by the Borg as punishment, because I am trying to make the code look nicer,
> just say so...

May I be honest :)
Trying to make the code look nicer and conform to the GNU coding
standards is fine. Actually doing it on the other hand...

Massive re-indentation should really be announced first so people can
sync up first to the current source and make preparations to handle
"flag day" when all code is changed at once.

In this particular case there are two unfortunate things:
- The native/fdlibm library isn't actually part of GNU Classpath, but a
upstream library we use. This isn't clearly documented, I have put it on
my list. In this case I think reverting it is the right thing to do. It
makes diffs with the original library easier.
- The native/jni/gtk-peer files are a proper part of GNU Classpath, but
currently mostly hacked on (maintained) on the libgcj gui branch.
Graydon said that he takes full responsibility for any inconvenience
this creates, but in this case I think this does make merging for him
much harder then it should be. The next merge/sync date for this code is
April 15 if I remember correctly. Maybe it is better to reverse this
till just after this merge point. Graydon?

For the rest of the code the re-indenting according to standard GNU
coding guidelines is actually an improvement. Thanks.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part