[fpc-devel] Errors with make rtl.chk on Windows
Michael Van Canneyt
michael at freepascal.org
Sat Dec 3 00:06:40 CET 2011
On Fri, 2 Dec 2011, Sven Barth wrote:
> On 02.12.2011 19:37, Michael Van Canneyt wrote:
>>
>>
>> On Fri, 2 Dec 2011, Sven Barth wrote:
>>
>>> Am 02.12.2011 17:21, schrieb Michael Van Canneyt:
>>>>>
>>>>> This means that we can document platform-specific items in additional
>>>>> files, which are automatically merged with the other descriptions. The
>>>>> description file specifications can be extended by a platform
>>>>> attribute, so that problems arising from multiple (platform specific)
>>>>> descriptions can be eliminated. E.g.:
>>>>> <description file="sysutils.xml"/>
>>>>> <description file="linux-sysutils.xml" platform="linux,unix"/>
>>>>> <description file="win-sysutils.xml" platform=windows/>
>>>>
>>>> I don't see the point of this. Why not simply add them to the
>>>> description file sysutils.xml ?
>>>>
>>>> <element> tags for which no source file identifier exists are discarded
>>>> anyway.
>>>>
>>>> If anything needs to be done at all, I see more use in adding a
>>>> 'platform' tag to the element tags themselves; That would give the
>>>> documentation generator useful information which it can use. In fact,
>>>> the 'platform' directive should in the first place be in the sources
>>>> themselves, where it will be picked up by the scanner/parser - as per
>>>> the remark of Marco.
>>>
>>> Out of curiosity: How could/would one create one documentation of
>>> source which supports multiple platforms, but where there are
>>> identifiers that are only available for some platforms? (like our RTL)
>>
>> You currently can't as long as the source files are different.
>>
>> And even with the same source file it is difficult, since the parser
>> will always parse only one branch from an IFDEF.
>>
>> {$IFDEF WINDOWS}
>> THANDLE = Handle;
>> {$ELSE}
>> THANDLE = Pointer;
>> {$endif}
>>
>> Cannot be parsed correctly. Same for library units with different
>> calling conventions etc.
>
> Somehow that's what I feared based on your explanation above (Note: I don't
> have the need for it currently, but I believe it's a "nice to have")
One workaround is to do something like is currently done in the RTL.
Let fpdoc define a conditional (e.g. FPDOCSYSTEM) and add dummy identifiers to the unit:
{$IFDEF FPDOCSYSTEM}
// Add definitions for fpdoc here which are normally not present.
{$ENDIF}
This way, they are documented, but not in the actual unit.
(unless someone actually wants to cheat the compiler and compile the unit with -dFPDOCSYSTEM)
Michael.
More information about the fpc-devel
mailing list