How to add a compile time configuration option to something in cpukit?

[Joel Sherrill]

Sebastian Huber wrote:
> Ralf Corsepius wrote:
>   
>> On 09/03/2009 01:41 PM, Sebastian Huber wrote:
>>     
>>> Ralf Corsepius wrote:
>>>   
>>>       
>>>> On 09/03/2009 01:35 PM, Sebastian Huber wrote:
>>>>     
>>>>         
>>>>> Ralf Corsepius wrote:
>>>>>
>>>>>       
>>>>>           
>>>>>> On 09/03/2009 12:18 PM, Sebastian Huber wrote:
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> Hi,
>>>>>>>
>>>>>>> the FTP client resides in the cpukit.  It can use gethostbyname() to
>>>>>>> obtain an
>>>>>>> internet address from a DNS name.  The dependency on DNS adds 35k of
>>>>>>> code
>>>>>>> (THUMB op-codes).  I want to add a configuration option to disable
>>>>>>> this
>>>>>>> feature.  Can I add this with RTEMS_CPUOPT in cpukit/configure.ac?
>>>>>>>
>>>>>>>            
>>>>>>>               
>>>>>> As I repeatedly wrote, before: All -m* flags must be global (i.e.
>>>>>> *.cfg)
>>>>>>
>>>>>> What you are trying to do violates the working principles of
>>>>>> multilibs,
>>>>>> so no way.
>>>>>>
>>>>>>          
>>>>>>             
>>>>> Sorry now I am a little confused.  What is the connection to multilibs
>>>>> if I can
>>>>> enable or disable DNS support in the FTP client?
>>>>>
>>>>>        
>>>>>           
>>>> Here:
>>>>
>>>>     
>>>>         
>>>>>    I want to add a configuration option to disable this
>>>>>   feature.  Can I add this with RTEMS_CPUOPT in cpukit/configure.ac?
>>>>>        
>>>>>           
>>>> "cpukit/configure.ac"
>>>>
>>>>
>>>>      
>>>>         
>>> So it is officially impossible to customize the cpukit via configure
>>> options?
>>>    
>>>       
>> Very oversimplified, more or less, yes.
>>
>> Cpukit shares the same philosophy as "libc". Only global compile time
>> options are allowed (e.g. optimization levels, enabling/disabling global
>> features (.e.g. networking, profiling, ...), etc. ).
>>
>> Per target/per bsp flags are not permitted, because they will be
>> non-functional in multilib'ed configurations.
>>     
>
> This is in the same category than profiling or debug support.  You can create a
> cpukit that has the same functions, but one supports
>
> open("/ftp/anonymous at www.rtems.com/robots.txt")
>
> and the other one supports only
>
> open("/ftp/anonymous at 67.63.146.250/robots.txt")
>
>   
Sebastian... you have to look at things from a very high level.  You
are down in the details and not seeing the entire picture.  There are
lots of configurable things in the CPU kit but almost all are done
at application configuration/link time.

ftpd already takes some configuration.  I would lean to modifying
the ftpd code such that it has this support plugged in by the
application when it configures/starts ftpd. 

For example, the malloc implementation had a lot of old conditional
features in it which are now application configuration time pluggable.

So configuration is good but compile-time configuration is bad.

--joel