[fpc-devel] extending platform flag request

[Sergei Gorelkin]

Tomas Hajny wrote:
> �авоН ��онин wrote:
>> Michael Van Canneyt wrote:
>>> I think it's better to implement a string message dispatcher for this
>>> instead of adding RTTI (which is already bulky as it is). Do not forget
>>> that the widget set is very lazarus specific, and has nothing to do with
>>> RTTI or even the OS/CPU platform that the compiler knows.
>>>
>>> So as far as I'm concerned, this is more of a no-no.
>> We can add some hint ofcource like {%widgetset carbon qt}, write special
>> parser for that, invent same as rtti structures to store string array of
>> supported widgetsets. OR it can be easyly fited into existed platform
>> keyword and without inventing second weel existed RTTI structure can be
>> extented with arrat of string.
>>
>> If it is not lazarus but say component set developed for several
>> platforms (libraries, os, whatever else) then platform string can be
>> 'win32 linux osx' (if property is valid only for 3 os) or 'oracle
>> interbase' (if property is valid only for 2 databases).
>>
>> Another advantage is that with extra info in platform keyword fpc will
>> have more informative platform hints.
>>
>> I see no disadvantages.
> 
> Where does the list of allowed values come from? How are the values
> validated during compilation (what happens if someone types 'qr' instead
> of 'qt' by mistake)? What would be the value of information stored this
> way if there's no validation at all?
> 

The informativeness of 'platform' hints could be improved by including a 
comment that is adjacent to the keyword, if one exists, e.g:

property SomeProp; platform; // qt and carbon only

Then hint will then be:
  property 'SomeProp' is platform-specific (qt and carbon only).

But this stuff REALLY has nothing to do with runtime...

Sergei