Re: GNU indent for C code

[Mark Wielaard]

Hi,

On Mon, 2004-03-29 at 00:45, Etienne Gagnon wrote:
> 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?

Added to the hacking guide.

Normally new hackers also get a welcome email from me explaining what to
do/what not to do, how to interact with the other hackers on the
project. I hadn't realized that you had gotten cvs commit access so long
ago so I never send you an email about what the current customs are.

Since there are actually quite some old hackers with CVS access that
might also not have kept up with current practices this is now actually
in the guide. Please read it if you have commit access but never emailed
with me about it.

> >>2- Add autogen.sh for hackers (script that calls auto* tools).
> > 
> > Thanks. Could you also update the HACKING file with this info?
> 
> Already done.

Thanks. But I saw that you removed it again.
I folded all the information of the HACKING file into the Hacking Guide
to make sure all relevant information is in the same place. So if you
readd it please add it to doc/hacking.texinfo instead.

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

I added a complete new section about how to create ChangeLog entries
based on the emails on the classpath-commit list from the last couple of
months.

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

That would be the correct solution indeed.
As it happens for us (as now also documented in the Hacking Guide)
libgcj is the upstream. It should not be hard to convince them to
reindent. But I am not sure they will be able to do the same for their
upstream.

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

It is about not making other hackers go to much more trouble then is
necessary. It is often a bit difficult when you are in the middle of an
hacking session on some part of the code to see a reindentation going on
at that same code without getting a proper warning that it is going to
happen. Since Graydon hasn't commented at all on this issue I want to
wait till he has a chance to give his opinion. But if he keeps ignoring
the issue we can go ahead anyway.

Cheers,

Mark

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