moving <limits> bits to config/cpu

[Phil Edwards]

On Thu, Aug 23, 2001 at 03:56:01PM -0700, Benjamin Kosnik wrote:
> > The (admittedly baroque) way that gcc handles its config files might help
> > us here.  If configure.* sets LIMITSH to not a single file but rather
> > a list of files which are then concatenated to form limits.h, then the
> > OS/limits.h can override the CPU/limits.h.
> 
> Hmm. Not quite sure what you are getting at. Would it be possible for you 
> to demonstrate?

Ach, I forgot LIMITSH wasn't set to a file at all, but a directory.

I was thinking of something analogous to config.gcc's tm_file or xm_file.
In configure.target we assign some variable (like "limits_headers" or
something) a reasonable default, like

  limits_headers=$cpu_include_dir/bits/hardware_limits.h

and then possibly append/prepend other files to the list, like

  case "${target_os}" in
    freebsd*)
      limits_headers="$limits_headers $os_include_dir/bits/bsd_limits.h"
  esac

Maybe we wouldn't want to put them in the "bits" subdir, since that
directory is being searched directly, but you get my point.

The later files could override earlier ones.  We could also leave
limits_headers blank initally, then run through the case statements,
and finally do

    limits_headers="$limits_headers generic/generic_limits.h"

which would set anything not already set.

Finally we construct a limits.h by doing

    for f in "limits_headers"; do
        cat $f >> limits.h
    done



Phil

-- 
Would I had phrases that are not known, utterances that are strange, in
new language that has not been used, free from repetition, not an utterance
which has grown stale, which men of old have spoken.
                                     - anonymous Egyptian scribe, c.1700 BC