Re: GNU indent for C code

[Michael Koch]

Am Montag, 29. März 2004 00:45 schrieb Etienne Gagnon:
> Mark Wielaard wrote:
> > 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.
>
> Could this be clearly documented on the web site, in a very visible
> location?
>
> >>2- Add autogen.sh for hackers (script that calls auto* tools).
> >
> > Thanks. Could you also update the HACKING file with this info?
>
> Already done.
>
> >>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.)
>
> Nitpiking of my own: This could be documented in a visible place too.
>
> I much prefer automatic changelogs, by I guess you people prefer
> hand written fine-grain ChangeLog entries with even the name every
> single modified function. :-(

Yeah, thats all written in the GNU Coding Style Guide.

> > 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.
>
> I disagree.  You can simply apply GNU Indent to the upstream code and
> compare the diffs to the result.  I have done this with
> Classpath->sablevm-native-library imports for over a year without
> problems.

Why add an extra step to make copmparision possible and the indentation 
doesnt gain you anything.

> Why?  fdlibm is one of the worstly indented pices of code I have
> seen. I won't comment on the general readability (I'll let you make
> your own opinion of that), but I really think that applying GNU
> indentation does very much help.
>
> If you really want to get "direct" diffs, I would rather encourage
> upstream to start using GNU indent!

A good way would be to get upstram use GNU indent first.

> > - 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?
>
> Same trick as above works pretty well.  I see no problem there.

You just make the work of others more hard. That is a pretty good 
reason.

> > For the rest of the code the re-indenting according to standard GNU
> > coding guidelines is actually an improvement. Thanks.
>
> I think it would be innaproproate to have 10 sorts of indentation
> (fdlibm counting for 8 of them), in Classpath.

Yeah, its bad but fixing the root of all evil first is better then to 
"fix" the satelites first.


Michael