[fpc-devel]Compilation of Apples Universal Interfaces

[Olle Raab]

04-08-16 10.31, skrev Dr. Rolf Jansen följande:

> I am with you to keep the number of changes to the PInterfaces as small
> as possible. However, I would like to make a distinction between buggy
> or misleading parts of the PInterfaces and those parts which simply
> belong to another flavour (presumably the Mac one).
> 
> A.  I advocate for debugging the UI´s and not to accommodate
> for bugs in the Free Pascal mode -Mmacpas.

I do not either want to accomodate for bugs.

My idea is to make fpc in mode macpas emulate Metrowerks Pascal, since this
is the most modern commercial pascal compiler for mac. And the compiler
today's active pascal programmers uses. Mode macpas should accomodate for
Think Pascal features.

And the Delphi mode of fpc sometimes support things in Delphi which is not
so nice, but not neccesarily bugs, because it should be possible to share
code between FPC and Delphi.

That said, we should of course not support all bad things in Metrowerks.

And perhaps it is good to be conservative and not implement everything right
now, at least not today :)

> B.  I advocate for improving the Free Pascal mode -Mmacpas in order
> to allow all Pascal Mac developers a smooth transition.
> 
> C.  I advocate for maintaining and improving the PInterfaces
> as time goes by since Apple will not do it anymore.
> 
> Examples for A:
> 
> IMHO the active LongDouble routines in fp.p and the use of the term
> "object" at several places belong definitely to category A. In fact,
> your example "SetDeskCPat" is deactivated with the {$IFC
> CALL_NOT_IN_CARBON} directive.

Sorry, you are right.

>IT IS the policy of the UI to
> activate/deactivate not used parts for different platforms/targets - by
> this way the interfaces became universal.

 But this one:

    {
     *  ScrollWindowRect()
     *  
     *  Availability:
     *    Non-Carbon CFM:   not available
     *    CarbonLib:        in CarbonLib 1.0 and later
     *    Mac OS X:         in version 10.0 or later
         }

is not deactivated for Non-Carbon CFM. I guess non-carbon calls is
deactivated, but not everything is properly deactivated, it is instead left
to the linker to complain about.

But ok, at least non carbon code should be deactivated under carbon.

> I doubt that the term LongDouble was ever used by Mac Pascal
> Programmers. LongDouble was known as extended. So, I suggest not to
> care about the LongDouble routines, but simply deactivate them for Mac
> OS X by encapsulating them with the conditional directive {$IFC
> TARGET_CPU_PPC AND NOT TARGET_API_MAC_OSX}.

OK.

But I will anyway add LongDouble for non Mac OS X. Because it is defined by
Metrowerks.

> I consider "object" to be a reserved word for Mac Pascal. So it is a
> bug to use it as record field names or in routine declarations as
> parameter names. There is no other way, "object" must be renamed in the
> UI´s.

Metrowerks do not treat object as an reserved word, thats why this bug is
not discovered. But I agree it is not nice. So rename.

> Example for B:
> 
> {$LibExport+} belongs definitely to category B. It might be a good idea
> to let Free Pascal accept this directive in -Mmacpas in the future,
> even if it does nothing special but simply ignor it.

OK, its added to the cvs. Its recognized but does nothing.

> Example for C:
> 
> The changes to the type declaration of CStringPtr/ConstCStringPtr from
> Ptr to PChar belong to category C. After thinking about it, I aggree
> with you that this more specific change is better compared to the more
> general change of Ptr from ^SInt8 to PChar.
> 
> It might be a good idea to surround changes of category C with the
> conditional compiler directive {$IFC NOT UNDEFINED FPC}.
> 
> This would mean in the given case that in MacTypes.p:
> 
> CStringPtr            = Ptr;
> CStringPtrPtr         = ^CStringPtr;
> ConstCStringPtr       = Ptr;
> ConstCStringPtrPtr    = ^ConstCStringPtr;
> 
> should be changed to:
> 
> {$IFC UNDEFINED FPC}
> CStringPtr            = Ptr;
> {$ELSEC}
> CStringPtr            = PChar;
> {$ENDC}
> CStringPtrPtr         = ^CStringPtr;
> ConstCStringPtr       = CStringPtr;
> ConstCStringPtrPtr    = ^ConstCStringPtr;
> 
> 
> If we follow these rules then no change of either category will break
> compatibility to old Mac compilers or different targets.

OK.

> I aggree with you that it would be great if Apple would allow us to
> distribute a patched version of the PInterfaces. In the meantime we
> have to go the diff and patch way.

In any case it is nice to have a diff file as a document of the changes.

Olle

BTW If you write in the wiki, consider to register as a user, it is then
easier to see who has written what, and to discuss that.