xlimits.h for embedded targets

[Joel Sherrill]

On Tue, 23 Sep 1997, Christian Iseli wrote:

> > Is this just a procedural change with no real impact on when the file is
> > built or the contents of the resulting file? 
> 
> 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
> 
> Thus the file will be "constructed" before it is needed by msc816.inc, which is a file
> containing some assembler macros, which is needed when the compiler driver assembles
> some cc1 output.

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 does not solve the more general problem that some of the
runtimes require a C library.  But this is a larger problem.

What do you guys think of the proposed solution?  Every system which
system which has a limits.h problem would end up with a limits.h in the
gcc source tree.  I would have to move the rtems specific limits.h file
from newlib to gcc/config/limits-rtems.h since the file is the same for
all rtems targets.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985