ralf.corsepius at rtems.org
Wed Apr 20 08:41:47 UTC 2005
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:
> >>How is that supposed to work? It broke applications that set LD_PATHS
> >>in their makefiles
> >Here you say it: "application ... makefiles"
> >gcc-target-default.cfg is part of OAR's brain-dead application makefile
> >template system and meanwhile (for several years) is not used by the
> >source tree anymore. As I have said dozens of times before, if I was to
> >decide about it, the application makefile template system was abandoned
> >years ago.
> >gcc-target-default.cfg suffers from the same flaws as all other
> >application makefiles: RTEMS has no chance to know what application want
> >nor which variables they want to use, and therefore can't care about it.
> >I.e. if something inside of the makefile template system doesn't meet
> >your applications' demands, change/edit it to your demands.
> >So I guess, all the changelog entry above is referring to is
> >streamlining gcc-target-default.cfg to what the RTEMS makefiles use
> >> [README qualifies LD_PATHS as a makefile variable].
> >Which README? Such a statement is wrong and would qualify as a
> >documentation bug.
> The <rtems_install_top>/make/README. The problem is that there _are_
> [I have a few] out there that use the makefile system and they rely on
> what that
> system has done in the past, so please don't break it.
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
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.
ATM, I am considering to insist on them being removed for rtems-4.7.
> 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.
More information about the users