Re: Projects for beginners

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Wed, Jan 31, 2001 at 07:17:16AM -0500, Richard Kenner wrote:
> There are two things in here that I'm not sure are such good ideas:
> 
>   Add multiple include guards to all header files.
> 
> I think this encourages sloppy use of header files.  I'd much prefer to
> have some standard ordering of header files that we adopt.

At the moment, we have a complex set of undocumented ordering
requirements on the headers.  We *could* document them all, but
personally I'd much rather go for the cheap technological fix.
Matter of taste.

Note that MI guards will cause the preprocessor to waste less memory,
because it won't keep the header text around for potential future
reference.  On expr.c, for instance, that'd save roughly 500K.

>   Get as much out of the x-host and xm-host.h files into
>   autoconf tests, system.h, etc., as possible.
> 	- I would give even odds that it can all go.
> 
> This is tricky.  Remember that they are also used for building the library
> and in the cross-compiler case you can't get them from autoconf.

Mm, I think you're thinking of the t-target files.  I read through
every last one of the x-host and xm-host.h files.  The settings in
there are, without exception, in one of these categories:

- Historical dead wood.  [Some files contain only comments!]
- Belongs in a tm.h or t-target file.  E.g. x-linux has no business
  saying not to run fixproto, xm-interix.h has no business specifying
  how to run global constructors.
- Belongs in system.h.  E.g. #define TRUE 1.
- Is a system category assertion, which should be replaced by feature
  checks, but we have to do work in machine-independent code first.
- Could perfectly well be determined by autoconf even when
  cross-compiling - with sufficient cleverness.  It may be infeasible
  to get everything, but there's no reason in principle why not.
  The hardest ones will be (SUCCESS|FATAL)_EXIT_CODE.  You might think
  the HOST_BITS_PER_* stuff would be impossible when cross compiling,
  but autoconf 2.50 knows how to do it.

I'm not saying that we will be able to casually dump them all.  I am
saying that I think getting rid of them all is a useful and feasible
goal.

zw