[fpc-devel] ctypes and RTL

[Ivo Steinmann]

Marco van de Voort schrieb:
> In our previous episode, Ivo Steinmann said:
>   
>>>>     
>>>>         
>>> Yup. The current situation took nearly a year (first renamings in may,
>>> finished with FPC_USE_LIBC in week between christmas and newyear)
>>>   
>>>       
>> yes, and that's exactly the code looks like. not clearly structured (at 
>> least concerning ctypes.inc and ptypes.inc and the alias include files 
>> required for keeping it consistent). 
>>     
>
> Sure. You won't be hearing from me that the situation is perfect. It had to
> keep compiling for two compiler versions during this transition. But a lot
> of that has been cleaned up. Ales and I still clean up little bits from time
> to time.
>
> My point is more that there is more than meets the eye, and you have to be
> very careful, and don't expect instant gratification of a major restructure.
>   
it's not that major restructure as it looks in the first shot. it's a 
very careful step.
> To start with, you need to abandon the one target only approach. To properly
> get this done you need to review several targets at once, since the
> situations are not plain copies of eachother.
>
> Also, keep notes. We wouldn't have this conversation if I had, and I lost
> some of the correspondence with Michael about the design when my machine got
> stolen.
>
>   
>> my changes are so small. for the 
>> users itself there's almost no change, except that they have to use 
>> UnixType unit also now, but that could be avoided by merging unixtype 
>> with baseunix and then dropping unixtype. 
>>     
>
> No, since unixtype afaik exports more than baseunix and would polute the
> namespace. There might also be circular dependancies involved. Fixing that
> will improve the structure, but lead to more code duplication and
> includefiles. 
>
>   
true, unixtype exports more than baseunix. in fact, unixtype exports the 
content of ptypes.inc (platform dependant) in it's interface. most of 
those types are reimported into interface part of baseunix and unix over 
aliasptp.inc (platform independant).
>> If really somebody uses unixtype, they simply remove it from uses clause.
>> in 99% of all cases unixtype is used together with baseunix.
>>     
>
> IIRC there were several reasons for unixtype
>
> - Only one place where the .inc files were important to avoid type
>   incompatabilities (e.g. when overloading)
> - most importantly:  platform dependant unit might use unixtypes BELOW
>   baseunix level, like bsd/sysctl (which is used by baseunix), maybe syscall
>   too. IOW system dependant units needed to implement baseunix.
>   Did you btw have a look at the unixrtl doc? The (admitted butt ugly)
>   graph demonstrates this. (http://www.stack.nl/~marcov/unixrtl.pdf).
>   These were inclusions before but these led to said type incompats.
> - I can vaguely remember this also allows strict control over the
>   identifiers that baseunix/unix export. Some of the more platform specific
>   constants in ptypes are not exported through the strictly portable baseunix
>   interface. Keep an eye on what exports what!
> - to avoid all users having to import 
>  
>   
yes, ptypes.inc are included only by UnixType and the system unit, while 
ctypes.inc is included by ptypes.inc. And that's exactly what I changed:

current situation:
ctypes.inc: all c types
aliasctp.inc: mapping of all ctypes defined in unixtype (over 
ptypes.inc) to locale scope
ptypes.inc: all unix platfrom (dependant) unix types. it also includes 
ctypes.inc
aliasptp.inc: mapping of all unix platfrom independant types + all 
c-types defined in UnixType to locale scope
unixtype: all unix platfrom (dpendant) unix types + all c-types
baseunix: includes aliasptp.inc
unix: includes aliasptp.inc

1. I removed {$i ctypes.inc} from each ptypes.inc
2. I removed {$i aliasctp.inc} from ctypes.pp and aliasptp.inc and added 
{$i ctypes.inc} instead
3. I added ctypes in uses clause of unixtype, baseunix and unix
4. I added ctypes.inc to system unit (because it's no longer included of 
ptypes.inc)

situation after changes:
ctypes.inc: all c types
aliasctp.inc: removed
ctypes.pp: includes ctypes.inc
unixtype: all unix platfrom (dependant) unix types

and that maybe not good, as you explained above:
aliasptp.inc: removed
baseunix: base funtionality with no types (because of removed aliasptp.inc)

if you keep aliasptp.inc, then only ctypes are outsourced from unixtype, 
baseunix and unix.

>> if somebody want to use a c-type, then include ctypes into uses.
>>     
>
> Ah, but I also use the ctypes in the implementation of the system unit. That
> is the trick of the current situation. The includes are used twice, but only
> once in the interface.
>
>   
yes

>> current situation you can simply include baseunix, then you have got 
>> your ctypes also. but then be consequent and add ctypes to windows unit 
>> also (and other oses). now for one os you have to use ctypes, for the 
>> other not -- really nice one.
>>     
>
> Because Windows doesn't have the concept of a system C compiler. Moreover
> due to the LLP64 choice, the 32-bit/64-bit types scale differently there.
>
> (long is 32-bit on windows 64-bit iirc)
>
>   
k

-Ivo