Port to CodeWarrier

[Steven Johnson]

>  I am trying to "port" the RTEMS installation under Cygwin32 into
>  CodeWarrier IDE for my MPC860 project. The only reason for this is the
> 860’s BDM support which the CodeWarrier debugger has.

I was attempting the same feat as you.
My commiserations.
I Gave up in disgust. The Build is so tightly bound to the GNU Toolset
that it was a continuous series of "Gotchas". I could have probably
moved the code for an MPC860 to a special version of RTEMS for MPC860
and CW, but that would of meant not being able to take ready advantage
of upgrades and fixes.

This was a real sticking point with me. The Compilation does not appear
to be that complicated, but it is made so much more difficult by having
"Unix" specific operations like ./configure scripts. This stuff is just
not portable to a non Unix implementation. It also requires GCC to
compile it, so that removes the ability to use the IDE Compiler. Things
like the Assembler statements being strewn with C Preprocessor
directives, which is not a standard practice for any Assembler Ive seen.

There is a real issue here. It seems that those that write These GNU
Programs expect people to be using Unix and GCC. The programs are very
heavilly targeted to these platforms. Moving to an alternate platform
invokes a whole world of pain. In my "opinion" this should be easy to
avoid, but it appears as if no one is really interested in the problem.

Things that would make life easier for those that dont use Unix or GCC:
1. Assembler Code Files that follows a standard Assembler format. (ie,
no C Pre-processor directives).
2. No ./Configure script. Replace it with a simpler make file. Yes you
have to maintain the make file, but you have to maintain the autoconf
script anyway, so it seems to be false economy to me.
3. Avoid Inline assembler as every implementation is different and the
GCC Implementation is especially bizare. If Inline assembler is
required, then surround it in an #ifdef GCC_INLINE_ASM block, so that
porters can add things like #elsif CW_INLINE_ASM the entire function
should be #'d this way, as some compilers do not allow Inline assembler
to be inserted mid stream of a function. (Code Warrior for example).

On the make file,
It should Include another file that defines all of the optional stuff,
each option should be commented. The make file should be as simple as
possible, and avoid GNU Make specific features, or if it uses them, they
should be commented in the makefile so that someone porting the makefile
can understand what piece of magic is being performed on the code. It
appears strange to me the way when the Code is built using GCC and Gnu
Make, how a seperate directory tree is created, this tree bears very
little obvious relationship to the original tree?? Also the act of
creating Header files at build time makes it very difficult when
perusing the code to find where things come from (it took me forever to
find where rtems/score/targopts.h was). ie, it is nowhere in the source
distribution.

Currently ive given up on using Code Warrior for code development, not
because it is a bed tool, it is excellent, rather because i cant get it
to build RTEMS. My fall back position is to compile the lot under Linux
using GCC (ie, its prefered environment, Unix and GCC). Im Hoping
against Hope that ELF and DWARF are really standards and the the Code
Warrior Debugger will read the Files produced by GCC and allow me to
debug. If it wont ill be forced to not use RTEMS at all, as i havent
seen a BDM Debugger for GDB, nor do i have the time to write one. :(

This is not a criticism of all the work that has been done in RTEMS. It
looks like a very good product, that has had a lot of thought put into
it. I can fully understand its tool dependencies, given this was the
environment it was created in. Still. it is disapointing that a project
like this isnt very accessable to anyone that chooses not to use GCC or
a Unix Variant.

One of the other factors that on RTEMS development that hinders this
sort of porting is not having ready access to in-development snap shots.
It seemed pointless to me to do all this porting effort to 3.6.0 only to
have to do it all again with 4.0.0. I Understand OARCORPs concerns here,
but i think a more open development would produce a better product in
the long run. Open Source code benifits from an open development model,
Pre-stable snapshots should be readily available, but they should be
marked as Prerelease snapshots, people can then use them or not at their
discretion. There is no waranty with Free software anyway, so i cant see
how it is a bad thing to have these snapshots available. If the problem
is traffic in the mailing lists like (Why doesnt it work), then you
could have two seperate mailing lists. General questions, and serious
core developement, restricting access to the later mailing list. (I
believe this is done now anyway.)

If you get it working id be very interested in information on how you
achieved it. Ill let you all know how well the Code Warrior debugger can
debug GCC ELF and DWARF Files.

Steven Johnson
Managing Director
Neurizon Pty Ltd.