[fpc-devel] ctypes and RTL

[Marco van de Voort]

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.

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. 

> 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 
 
> 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.

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

> same for unixtype, baseunix and unix... all these 3 units define the 
> same types (while unixtype is the master, and baseunix and unix uses an 
> alias include to it). what's the idea having 3 units defining the same 
> types? why not making a clear situation and say:

See above. A little bit of ugliness, but it hides a lot of code duplicatio n
(for each target again), while maintaining type compability. If it riles you
so much to import ctypes, you could investigate the ctypes types to baseunix
aliases maybe.

> 1. unixtype defines all unixtypes and baseunix some base functionalty
> or
> 2. let's drop unixtype and therefore baseunix defines all base types and 
> functionality.

That's not possible.