[PATCH] more miscellaneous cleanup in dbus core

[Havoc Pennington]

Hi,

Simon McVittie wrote:
> If we compile with -ansi (caused by ./configure --enable-ansi)

Oh, I missed that context somehow, I must have read too quickly ;-)

Now I'm just wondering why --enable-ansi exists; my usual view is that 
-ansi (and especially -pedantic) are silly, because we are properly 
testing that we have gcc before using gcc-isms, and so gcc-isms are just 
fine. In general I think -ansi -pedantic are "break my compiler" kind of 
flags.

> inline keyword isn't recognised, because gcc -ansi claims to implement
> ISO C90, and inline was only added in C99 (although everyone implemented
> it as an extension already). __inline__ is always implemented by gcc, for this
> reason.

So bizarrely we use something more gcc-specific to avoid a warning ;-)

The intent is that on a compiler without inline we would "#define 
inline" to nothing, and that we always use inline with "static" so this 
is safe to do.

> Looking more closely at how --enable-ansi and that function interact, it
> seems that it's meant to be disabled in an --enable-ansi build (although if
> someone uses CFLAGS=-ansi it'll get enabled in any case), but someone
> has got the autofoo completely wrong (code that's only meant to trigger on
> Darwin is actually enabling the i486 atomic ops indiscriminately on all i386
> or x86-64 machines, oops). I have most of a patch, which I'll finish
> tomorrow.

This would be good to mop up. If you want to destroy --enable-ansi I'm 
fine with that too, unless someone pipes up and says what it's supposed 
to be good for.

If it's just for attempting to simulate the not-gcc case with gcc, we 
should probably name it --enable-no-gccisms or something, and in 
addition to -ansi -pedantic, go ahead and avoid using the GNU extensions 
entirely rather than trying to keep the compiler from warning about them.

> I added a ChangeLog entry for the _try_ stuff just before pushing, and I
> intend to do the same for all the other branches

Thanks

> - ChangeLog seems likely
> to become some sort of hideous nexus of merge conflicts if we mandate that
> every commit on every branch touches it (which is why Collabora projects are
> all SCM-log-only, with ChangeLog generated by running git or darcs during
> `make dist`, and commit messages required to be sensible).

Well, I'll refer you to this thread which seems to debate both sides of 
the matter:
http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00198.html

I don't think ChangeLog merge conflicts are hard to deal with, and I 
don't think SCM logs turn out as well as the ChangeLog format. Now, if 
the SCM automatically generated the ChangeLog entry skeleton with file 
and function names and stuck that in the editor when I went to commit - 
that would be the best of both worlds perhaps. In the meantime I like to 
use 'C-x 4 a' to build up a log.

Havoc