[fpc-devel]Compilation of Apples Universal Interfaces

[Dr. Rolf Jansen]

Nothing more to say about it, since I see we are in total agreement.

- I will produce a diff file or the changes in the Universal 
PInterfaces.
- If I ever submit any change to the MacPas wiki page, I will do it as 
a registered user.
- I will update the Xcode-FreePascal site soon with the latest 
development.

Thank you very much Olle and Jonas.

Best regards

Rolf

Am 16.08.2004 um 13:50 schrieb 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.
>
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
>
__ InstantWare ______________________________________________________
  Dr. Rolf Jansen * Stephanienstraße 19 * D-76133 Karlsruhe * Germany

  http://InstantWare.bei.t-online.de/
_____________________________________________________________________