forked from Imagelibrary/rtems
e81ef51bf1826fe65cb75449ba2f6f1bc7899233
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.
IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
esac],[RTEMS_USE_GCC272=yes])
3) At the end of c/src/exec/score/cpu/m68k/m68k.h
> #ifdef __cplusplus
> }
> #endif
>
> #endif /* !ASM */
in my opinion these two statements should be swapped:
> #endif /* !ASM */
>
> #ifdef __cplusplus
> }
> #endif
I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.
Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.
I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.
Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.
Peanuts sofar, ... but here it comes ... (:-)
8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.
Motivation:
* Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
* Fix -pipe problems
* Fix problems with hard-coded paths in configuration files (esp. posix)
* Fix consistency problems with explictly given gnutools and gcc's gnutools
Currently included:
* detection and checking of host and target compiler (gcc/g++)
* checking if target gnutools are in path
* checking if <target>-gcc -specs works (autodisabling gcc28 if not)
* checking if <target>-gcc -pipe works
Todo :
* *posix.cfg files are not yet adapted => The hard-coded paths for these
systems are still in use.
* Check if the host compiler $CC is properly propagated to the Makefiles (I
doubt it, but this should not matter)
* Check if rtems' generic tools still work properly (It looks like, but who
knows)
* Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks
like C++ support is only used by posix BSPs)
* Automatically handle RANLIB/MKLIB for targets
* Plenty ... (:-)
Open problems:
* Untested for non-gcc compatible host and target compilers. This should be
no problem if the tools are named follow gnutool's naming convention and are
included in $PATH while running configure.
* Intentionally using different tools than that gcc has been configured for,
e.g. use a different assembler ? This should be still possible if
XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody
should want to do this, but who knows?
I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).
I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).
I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).
#
# $Id$
#
Building RTEMS
==============
See the file README.configure.
Directory Overview
==================
This is the top level of the RTEMS directory structure. The following
is a description of the files and directories in this directory:
INSTALL
Rudimentary installation instructions. For more detailed
information please see the Release Notes. The Postscript
version of this manual can be found in the file
c_or_ada/doc/relnotes.tgz.
LICENSE
Required legalese.
README
This file.
c
This directory contains the source code for the C
implementation of RTEMS as well as the test suites, sample
applications, Board Support Packages, Device Drivers, and
support libraries.
doc
This directory contains the PDL for the RTEMS executive.
Ada versus C
============
There are two implementations of RTEMS in this source tree --
in Ada and in C. These two implementations are functionally
and structurally equivalent. The C implementation follows
the packaging conventions and hiearchical nature of the Ada
implementation. In addition, a style has been followed which
allows one to easily find the corresponding Ada and C
implementations.
File names in C and code placement was carefully designed to insure
a close mapping to the Ada implementation. The following file name
extensions are used:
.adb - Ada body
.ads - Ada specification
.adp - Ada body requiring preprocessing
.inc - include file for .adp files
.c - C body (non-inlined routines)
.inl - C body (inlined routines)
.h - C specification
In the executive source, XYZ.c and XYZ.inl correspond directly to a
single XYZ.adb or XYZ.adp file. A .h file corresponds directly to
the .ads file. There are only a handful of .inc files in the
Ada source and these are used to insure that the desired simple
inline textual expansion is performed. This avoids scoping and
calling convention side-effects in carefully constructed tests
which usually test context switch behavior.
In addition, in Ada code and data name references are always fully
qualified as PACKAGE.NAME. In C, this convention is followed
by having the package name as part of the name itself and using a
capital letter to indicate the presence of a "." level. So we have
PACKAGE.NAME in Ada and _Package_Name in C. The leading "_" in C
is used to avoid naming conflicts between RTEMS and user variables.
By using these conventions, one can easily compare the C and Ada
implementations.
The most noticeable difference between the C and Ada83 code is
the inability to easily obtain a "typed pointer" in Ada83.
Using the "&" operator in C yields a pointer with a specific type.
The 'Address attribute is the closest feature in Ada83. This
returns a System.Address and this must be coerced via Unchecked_Conversion
into an access type of the desired type. It is easy to view
System.Address as similar to a "void *" in C, but this is not the case.
A "void *" can be assigned to any other pointer type without an
explicit conversion.
The solution adopted to this problem was to provide two routines for
each access type in the Ada implementation -- one to convert from
System.Address to the access type and another to go the opposite
direction. This results in code which accomplishes the same thing
as the corresponding C but it is easier to get lost in the clutter
of the apparent subprogram invocations than the "less bulky"
C equivalent.
A related difference is the types which are only in Ada which are used
for pointers to arrays. These types do not exist and are not needed
in the C implementation.
Description
RTEMS is a real-time executive in use by embedded systems applications around the world and beyond
Languages
C
93.9%
Assembly
3.4%
Ada
1.4%
Python
0.3%
HTML
0.3%
Other
0.4%