Intec Automation SS555 Port

[Ralf Corsepius]

On Thu, 2004-02-05 at 21:11, David Querbach wrote:
> On Thu, Feb 05, 2004 at 01:19:48PM -0600, Joel Sherrill wrote:
> > 
> > From your description, I see no technical reason why this wouldn't
> > be an acceptable submission.  I see no mention of modifications
> > to anything that should impact other CPUs or BSPs.
> 
> That's been a major goal of ours.
>  
> > The biggest issues facing this submission will be dealing with
> > merging it.  There are two issues there.
> > 
> > (1) The development trunk where this would be merged has had a
> > LOT of work done on the configure and make infrastructure and
> > this will have to be addressed.  The best approach here is to
> > merge it against the next snapshot which will be coming as soon
> > as some test sweeps are completed.  All testing was focused on
> > 4.6.0 so the snapshot side needs some sanity checking.
> 
> Our current work is based on the 4.6.0 branch, since our customer wants a
> stable release.  We'll need to get that complete before we could merge our
> work into a development branch.  
> 
> Can you provide a brief summary, or some sort of a readers guide, to the
> configure and make changes?

OK, Joel has asked me to step in - A LOT has changed.

First of all: The actual sources (*.c,*.S,*.h) and their location in the
source-tree only differ marginally between 4.6.0 and current development
sources. It's not clear yet, if and when changes there might happen, and
if and when such changes would be back-ported to a potential 4.6.1.

What has changed a lot is the Makefile.ams and their working principles
in general:

* We now use automake-compilation rules in cpukit and c/src/. Side
effects of this:

- Dependency tracking

- A step towards portable Makefiles

- Safer, less error-prone Makefiles

- FAR less Makefile.ams (ATM ca. 400, instead of ca 1000 as with 4.6.0),
using flater sub-package configurations

* Preinstallation rules (make preinstall and its infrastructure in
Makefiles) has been redesigned. Makefile.ams now use explicit
pre-installation make-rules being semi-automatically generated by a
script.

* Parallel make (make -j) is supported.

* VPATHS in Makefile.ams have been eliminated.



=> Side-effects on BSP implementors:

Configurations of BSPs outside of the source-tree (including 4.6.0
compatible BSPs) require adaptation.

On the implementation side, you will have to change very few lines in
your BSP's configure.ac and to implement a new
libbsp/<cpu>/<bsp>/Makefile.am based on your older <bsp>/Makefile.am and
<bsp>/*/Makefile.am.

This sounds much more complicated that it actually is. Having a look at
the BSP inside of the source-tree that resembles to your actual BSP most
and adapting your BSP to it should not be "that complicated".


=> Side-effects on porters:

cpukit and c/src/lib/libcpu's configurations are incompatible. You'll
have to adapt your Makefile.ams to it.


Easiest way to get that done: Submit your changes to www.rtems.com
and/or pay someone for it ;)


Current status:
* Things basically work.
* Some details require to be looked after.
* rtems-cvs-trunk building is being tested with gcc >= 3.3. There are no
plans to adapt RTEMS-4.6.x to gcc >= 3.3.
* AFAICT, there are no runtime experiences with gcc >= 3.3, yet.

Finally, the original release plan on 4.7 was (is?) fairly
(unrealistically?) ambitious: 4.7 was scheduled to be released shortly
after gcc-3.3.3 and/or gcc-3.4, which would mean 6-8 weeks from now.

Given my experience with the release of 4.6.0, I would have to lie to
find this schedule realistic. Anyway, I would expect a release of 4.7.0 to
happen very much earlier than most people will expect ;)

Ralf