Intec Automation SS555 Port

[Joel Sherrill]

Thanks Ralf.

I have updated http://www.rtems.com/rtems-4.7/index.html to
mention the build infrastructure changes and link to this post.

If you think it is necessary to add more information, then
I think the best thing to do would be to add a page to
the website under rtems-4.7/ and link to it instead of
this post.

The website is available from CVS so patches are accepted.
Any modifications committed to the repository will automatically
become visible when the website is refreshed and republished at
11:59 Huntsville time (CST).

--joel


Ralf Corsepius wrote:
> 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
> 
>