RTEMS build process

[joel at OARcorp.com (joel at OARcorp.com)]

On Wed, 24 Feb 1999, D. V. Henkel-Wallace wrote:

>    Date: Wed, 24 Feb 1999 13:56:30 -0600 (CST)
>    From: <joel at OARcorp.com>
> 
>    Another more general issue is that some of this stuff is hard because you
>    need the -B... -specs ... -qrtemsXXX combination to pick up a BSP.  Since
>    you and Ian are the best folks on the list to help on this, I would like
>    to see a better way to tell gcc which RTEMS BSP to use.   Doing this
>    should all of the above.
> 
>    Something like:  -Xrtems-bsp=ABC would tell gcc to look at its
>    $(prefix)/rtems/ABC/lib/ and do the equivalent of the -B... -qrtems.  I
>    don't know how to get the equivalent of -qrtems_debug though.
> 
> I believe the custom specs stuff is fragile, and probably a bad idea
> (I liked it at first, but...).
> 
> I understand the motivation.  IWBN to ship the OS, BSPs, etc as .a's
> and then let the user link it all together at runtime.  It's a great
> goal.  Unfortunately I don't think that link-time customisation is
> worth the tradeoffs.
> 
> We certainly don't use it that way.  A system build for us builds
> RTEMS and our code, then links it.  I suspect most people are
> similar.

Maybe so, maybe not.  I know that internally on projects, we develop on a
simulator and then transition to the real hardware.  For us, it is a
selling point to our customers when we using the same toolset since we can
(honestly and with confidence) say that the toolset is EXACTLY the same --
the only different is the RTEMS BSP and device drivers.

We have done this with psim and a PPC603e target.  I believe the SPARC
erc32 has users doing the same thing.  Even worse, I know that we actually
did use multiple BSPs through much of the life of one application I worked
on.  It was unclear which would be in the final system until the last days
of the development.  On that project, we would have had 3 custom toolsets
with no shared binaries.  Each toolset was 100's of Mbytes.

If there were not a simulator for the cpu in the target, I would still be
prone to test on a simulator for another CPU to debug most application
code, then move to the real target hardware.

Someone periodically reminds me that I am not the typical user. :)  In the
past, I have argued for high degrees of flexibility that most people don't
need.  

I would welcome a proposal that let us have our cake and eat it too.  My
idea is a script or configure option that says I want a single BSP toolset
or a multiple BSP toolset.  Much simpler for users who only need one BSP
but still flexible for others.

> In the embedded space, one has lots of different processors, and (as
> we can see from the guy using the 486SX the other day) many of them
> necessitate a rebuild anyway -- even custom tools.

GCC's (lack of) handling of ix86's without hardware FPU is independent
from RTEMS.  If gcc had software FP emulation for the i387, then people
using cpus like the i486sx and i386ex would not be having this level of
difficulty. 

aving to fix the toolset is different from having to localize/customize
the toolset.

> And once you've rebuilt, you're probably building for only one BSP.
> for those who are not, or are in transition, building the entire RTEMS
> twice will hardly be the dominating cost.
> 
> Thus I think it would be simpler to make all the config info explicit
> in the makefiles.  It'll be easier for people not using GNU as well.

One of the motivations to using gcc and hiding details is that higher
level tools tend to invoke gcc to link executable.  I started down the
path of linking via gcc to support GNAT.  It has a nice utility called
"gnatmake".  You point it at the "main" and tell it you want an
executable.  It figures everything else out, compiles all necessary
pieces, and links them together for you using gcc.  

Using gcc to link is done on most (nearly all?) configurations of gcc and
I did not want RTEMS to be different.

Besides getting and keeping the ld command right for every target was more
error prone.

> I know that vxWorks and its ancestor, pSOS ship binary distributions
> (exclusively?); probably some other RTOSes like OS9 do as well.  So
> maybe OAR has a some corporate pressure in this area.  In that case
> you probably will have to ship special compilers anyway -- and you can
> do the BSP specs hack right in the configuration!

I don't get at what you think we feel corporate pressure about.  We would
like to ship CDs with tool binaries for common configurations.  I know
that in some cases it may be necessary to hack the tools but in general,
it is not needed.  

When you use libgloss+newlib, all you have to do is specify a couple of
command line options to gcc to switch boards.  I don't see why RTEMS has
to be substantially more difficult. 


--joel