[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU indent for C code
From: |
Michael Koch |
Subject: |
Re: GNU indent for C code |
Date: |
Mon, 29 Mar 2004 10:12:37 +0200 |
User-agent: |
KMail/1.5.4 |
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