|author||Joel Sherrill <joel.sherrill@OARcorp.com>||1998-07-17 15:17:29 +0000|
|committer||Joel Sherrill <joel.sherrill@OARcorp.com>||1998-07-17 15:17:29 +0000|
|parent||Patch from Dario Alcocer <firstname.lastname@example.org>. His comments: (diff)|
New files from Ralf Corsepius <email@example.com>. His comments:
* c/src/exec/score/tools/sh - NEW DIRECTORY - contains shgen Most of it should be self-explanatory. I am a little bit concerned about host-dependent features (getopt, floating point libraries). This shouldn't disturb much now, as this tool should be compileable on all gnu-based hosts and is only applicable for the sh. But in case somebody complains, we may need to add autoconf checks or even restructurize parts of rtems (IMO, rtems needs to be restructurized - remember the "turning rtems upside down" issue).
Diffstat (limited to '')
1 files changed, 13 insertions, 0 deletions
diff --git a/tools/cpu/sh/TODO b/tools/cpu/sh/TODO
new file mode 100644
@@ -0,0 +1,13 @@
+* Add support for more drivers to shgen !!!!
+* shgen relies on having a gnu-compatible getopt, which should be
+ available on all hosts using gcc/egcs/binutils.
+ Using other getopt-variants may produce faulty results or shgen may also
+ refuse to compile. Probably the easiest solution to this problem would be
+ to integrate libiberty into rtems.
+* shgen uses floating point mathematics. Therefore Makefile.in contains a
+ reference to libm. In case the host doesn't have its floating point
+ support in libm, shgen will fail to compile. If we should ever meet such
+ a host, checks for floating point libraries have to be added to rtems'
+ autoconf support.