commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU indent for C code


From: Etienne Gagnon
Subject: Re: GNU indent for C code
Date: Sun, 28 Mar 2004 17:45:24 -0500
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6) Gecko/20040314 Debian/1.6-3

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. :-(

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?  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!

- 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.

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.

Etienne


--
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]