I've been a long time Pascal programmer on the Mac, and I'm just starting to look at ways to get the Mac OS API interfaces working with gpc to allow porting of Mac Pascal programs to gpc/Mac OS X and writing of new programs. The latter requires only hacking the Mac API files sufficiently to work with gpc, the former requires easing the burden of moving code from the traditional THINK/CodeWarrior Pascal compilers to gpc.
Some tasks are best done by changing the source files, but other tasks would be much easier done with modifications to gpc to support some of the Mac constructs (eg univ untyped pointers, external names that match exactly the procedure names, some minor things like, and some major things like binary compatible "short" strings (this is a big one), closer object modal (this is a huge amount of work, either in gpc or in porting)). I understand that there are god ideological reasons for not wanting some of these things, it's just that a lot of existing Mac Pascal code has good practical reasons for wanting these changes (personally, I have an active project with 300 Pascal files and 100,000 lines, and it would nice to be able to switch from CodeWarrior's unsupported Pascal compiler to gpc, but it's going to be a hard slog!).
So before I go to far with this, my question is, if we were to manage to modify gpc (in safe and sensible ways), and if the modifications were hidden unless some sort of compiler switch was enabled (perhaps --traditional-mac-compatible or whatever, possibly on by default when compiled on Mac OS X), would those changes be added back in to the gpc code base? Or is the policy more along the lines of "no, that's not X Y or Z standard, so it has to be patched in afterwards"?
Thanks for some meta advice on how to proceed in getting gpc accessible on Mac OS X, Peter.