xlimits.h for embedded targets

[Joel Sherrill]

On Wed, 8 Oct 1997, Jeffrey A Law wrote:

>   In message <Pine.BSF.3.96.970923085411.19118I-100000@vespucci.advicom.net>you  write:
> 
>   > On Tue, 23 Sep 1997, Christian Iseli wrote:
>   > > The impact is that the proposed change lets the target file t-target
>   > > overide the way limits.h is constructed.  For example, my target file
>   > > t-c816 defines it as
>   > > 
>   > > # Target specific header files
>   > > LIMITS_H = limits-c816.h
>   > > 
>   > > limits-c816.h: $(srcdir)/config/c816/limits-c816.h msc816.inc
>   > > 	cp $(srcdir)/config/c816/limits-c816.h limits-c816.h
> Well, I'd prefer to see this work more like FLOAT_H/CROSS_FLOAT_H, which
> should give you the same basic functionality.  Why invent two completely
> different mechanisms to solve the same basic problem.

The RTEMS limits.h file is technically dependent on the OS version.  In
practice, it doesn't change very often but it includes some limits from
the threads and real-time extensions

>   > Joel Sherrill wrote:
>   > Building RTEMS has a similar problem.  For lack of a better thing to do, I
>   > put our limits.h in newlib (C library) which is not built until after the
>   > compiler is built.  This solution would have allowed me to put the rtems
>   > limits.h file in the gcc source tree and it would be available when
>   > required during the build.
> This alternative is pretty simple too -- gcc looks for a suitable limits.h
> in the target include area $(SYSTEM_HEADER_DIR)/limits.h and puts some
> wrappers around it if it exists.

This is why I remove the one generated on the first pass and let gcc
reinstall the one built with the wrapper.  

>   > This does not solve the more general problem that some of the
>   > runtimes require a C library.  But this is a larger problem.
> Yup.  We just have to keep chipping away.

And things are slowly getting better.

I think that if the generation limits.h, libgcc.a, and other target
dependent libraries were put in their own subdirectoriies with their own
Makefiles, then the top level make could just arrange to do things in the
right order.  It might require splitting the headers and bodies of a C
library into 2 pieces so the .h's would be available at the right time but
that is about it.  I think it is more of a reorganization than anything
else. 

This one will just take time to settle out.

--joel