guile-devel
[Top][All Lists]
Advanced

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

Re: Moving #include <stdio.h> into _scm.h


From: Mikael Djurfeldt
Subject: Re: Moving #include <stdio.h> into _scm.h
Date: 10 Mar 2001 18:03:44 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Dirk Herrmann <address@hidden> writes:

> On Sat, 10 Mar 2001, Keisuke Nishida wrote:
> 
> > At Sat, 10 Mar 2001 09:18:55 +0100 (MET),
> > Dirk Herrmann wrote:
> > > 
> > > > Hmm... I'd rather go in the other direction: Remove things from _scm.h
> > > > that not all files need and remove #include <stdio.h> from files which
> > > > don't use stdio.  I'm sure that only a minority of the 79 files
> > > > including stdio really needs it.
> > > 
> > > Yes!  It's annoying if files get rebuilt that don't actually need to if
> > > some include file changes.  With system headers, this occurs less
> > > frequent, but it's definitely true for all libguile headers that are
> > > included via _scm.h.
> > 
> > But it is annoying to me to include such common headers as stdio.h
> > in each file...  Since _scm.h already includes errno.h, you have to
> > recompile all files anyway if you update your system headers.
> 
> As I see it, errno is only needed in files that do system calls.

I've removed #include <errno.h> from _scm.h and added it in files
making system calls + files manipulating the errno location.

This is 20 out of 100 files.

Actually, I think the main advantage of this change is that it removes
a bit of "magic".  It can be confusing during debugging that, out of
all system header files, errno.h is treated specially.

The list of headers at the top of the file can actually be seen as
more than annoyance: They are a bit of information about what the file
is involved with.  (Now, that *would* be true if we were a bit more
tidy with updating those includes... :)

Anyway, hopefully Guile compiles just a little faster now, *and* only
approx. 20 files will be recompiled when the system headers change!
8-)

Best regards,
Mikael



reply via email to

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