[Pythonmac-SIG] Re: API_MAC_CARBON

[Steven D. Majewski]

On Wed, 1 Nov 2000, Jack Jansen wrote:

> 
> > Well - I did take a stab at the Win module. 
> > There are differences between the Carbon headers in the Carbon.framework
> > and the carbon supporting headers in Univeral Interfaces -- mostly for
> > backwards support. For example, MacWindows.h is the preferred file now.
> > In UI, there's a Windows.h file that is just a shim that includes 
> > MacWindows.h. That's not in C.F. 
> 
> I think you should try this just as a proof-of-concept first: simply hack up 
> the Winmodule.c file to include MacWindows.h (from Carbon.framework, I would 
> guess) and rip out the stuff that doesn't exist there (possibly you'll have to 
> copy some MacPython header files and rip stuff out of there too, but maybe 
> just removing the includes of those headers from Winmodule.c is good enough). 
> Then try to build a dynamic module for this with the normal (unix) tools.
> 

That's what I was aiming for -- to manually hack one module into building,
and then, after learning the gotcha's, figure out how to automate the
process. I haven't given up on that -- I just found that there's more
hacking required than I expected -- I need to do an OSX macglue and port
some other support routines  before I can do a complete build. 

BTW: I assume that the current modules are linked against InterfaceLib
and not CarbonLib -- true? If they were Carbonized, and IF they were 
linked to CarbonLib and not InterfaceLib, and IF they weren't linked
to GUSI or WASTE, etc. then they (the toolbox modules, not the Python EXE)
would work on OSX if we added a CFM loader shim to support both mach-o
and CFM for dynamic import. ) 


> For the future we can use conditional compilation (which bgen now supports) to 
> make a distinction between compiling-for-carbon-MacPython and 
> compiling-for-unix-like-Python.

See above. I think there should be Carbon and Non-Carbon (both OSX and OS9)
modules, and the Carbon stuff *SHOULD* be fairly source neutral 
( I think some of the Apple example code has conditionals mainly for
  Metroworks compiler vs. OSX gcc based compiler. ), and *IF* we 
get the linking + loading problems out of the way, the same Carbon modules
could work on either. But even if we don't aim for that, yes -- there 
ought to be one conditionally compiled MacWindows (Win) module 
eventually. 

---|  Steven D. Majewski   (804-982-0831)  <sdm7g@Virginia.EDU>  |---
---|  Department of Molecular Physiology and Biological Physics  |---
---|  University of Virginia             Health Sciences Center  |---
---|  P.O. Box 10011            Charlottesville, VA  22906-0011  |---
		"All operating systems want to be unix, 
		 All programming languages want to be lisp."