LD_PATHS

[Till Straumann]

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:
>>>      
>>>
>
>  
>
>>>>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
>>>themselves.
>>>
>>> 
>>>
>>>      
>>>
>>>>[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_ 
>>applications
>>[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'
>brokenness.
>
>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
>applications.
>
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.

>
>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. I guess you say 
'spec file' and yet this
   has to picked up from somewhere.
 - BSP specific rules to generate a bootable image

>
>ATM, I am considering to insist on them being removed for rtems-4.7.
>
How about deprecating and *freezing* them first? Currently, I have other 
problems
than implementing another makefile system. The current one works just fine.

>
>  
>
>>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 ;-)

T.

>Ralf
>
>
>  
>