In our previous episode, Ivo Steinmann said:
Show quoted text 8 lines
>>
>
> 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.
