ralf.corsepius at rtems.org
Wed Apr 20 10:03:47 UTC 2005
On Wed, 2005-04-20 at 01:55 -0700, Till Straumann wrote:
> Ralf Corsepius wrote:
> >On Tue, 2005-04-19 at 20:28 -0700, Till Straumann wrote:
> >>Ralf Corsepius wrote:
> >>>On Tue, 2005-04-19 at 17:25 -0700, Till Straumann wrote:
> >Well you are just facing the symptoms of the makefile templates'
> >Read what you wrote: "applications ... they rely ... don't break it"
> >This is the trap the Makefile-templates are stuck in: They can't be
> >changed, not any feature can be removed from them, RTEMS would have to
> >stick with anything having ever been introduced somewhere, sometime.
> >The only resolution to this dilemma from an RTEMS perspective I see, is
> >to officially announce them dead.
> >Then _you_ would have to maintain these inside of your applications, or
> >you would have to implement an add-on package to RTEMS to cater your
> Fine with me if the RTEMS/BSP specifica can be cleanly separated out.
> The problem I had
> since the beginning (i.e., when I started doing RTEMS) was that I *had*
> to use that makefile
> system in order to get the right specs, BSP build rules etc.
This should have improved now.
All you need to know is:
* The correct CFLAGS to pickup the correct multilib - This problem is a
not an RTEMS problem, it is a general one, you have on all OSes.
* The bsp_specs for your BSP and the directory it can be found.
-B<whereever>/ --spec <bspspec>
* The link/building bootimages rules (cf. below) and the MANAGERS magic.
These are still open problems.
> >However, there is one big difference between the current situation and
> >this situation: Unlike RTEMS, you know what your applications want and
> >have any freedom adapt it to your demands at any time.
> Hmm - there are still two issues that come to my mind which are not
> application dependent:
> - how to pick compiler options, linker scripts etc.
Consider this: RTEMS is the OS, applications are using the OS.
=> Like on any other OS it should be your application's rsp. the "system
integrator's" task to choose appropriate compiler options.
> I guess you say
> 'spec file' and yet this
This would be one option.
> has to picked up from somewhere.
Yes, e.g. where you tell your application to pick it up from.
Another option is using pkgconfig or you using appropriate autoconf
> - BSP specific rules to generate a bootable image
This is an open problem, having been on my agenda for years :(
Unfortunately there still are too many open issues (One roadbloack ist
the makefile templates; another one is lack of consistency in make
suffix rules being used in BSP.cfg) related to it to implement the
implementation I have in mind, nor did I find sufficient time to
1. Split building bootimages into 2 steps:
a) link the application binary (eg. *.exe).
b) convert the "binary" into a bootimage (eg. *.bin)
2. Implement the 2 steps from 1. into suffix rules in BSP.cfg.
3. Implement scripts using a unified command options for step 1.b). In
an ideal world, we would have a single unified tool for all targets/BSP.
Until now, I have several times tried to implement step 1. and 2., but
had given in frustrated, because people rejected it as "too massive" and
"breaks" existing applications :(
Therefore, you've got, what you've got ;)
> >ATM, I am considering to insist on them being removed for rtems-4.7.
> How about deprecating and *freezing* them first?
>From my point of view they have been _dead_ and unmaintained since
> >>Call it a documentation bug
> >>but since that documentation bug has been out there for a long time it's
> >>dangerous to assume that nobody uses the documented features...
> >Ask Joel, he is the person in charge of the application makefile
> >fragments - I refuse to look into them.
> You didn't refuse to make that change though ;-)
Note the date: 2002 - IIRC, at that time gcc-target-default.cfg had
still been used by the source tree.
I recall having removed many of the (now unused) variables having been
used by the Makefile fragments since them until I finally managed to not
use them at all, anymore - I also recall that pretty unpleasant
discussion on GNATS :)
More information about the users