[Pythonmac-SIG] Problems compiling matplotlib; OR, how to make headers accessible in OS X?

[Bob Ippolito]

On Jul 13, 2004, at 9:49 PM, Kenneth McDonald wrote:

> I'm attempting to compile matplotlib, and get messages saying that
> it can't find the headers for Tcl/Tk. They exist, they just happen to
> be in the Frameworks directories for Tcl and for Tk. I know I can
> get this to work by hacking (setting up path variables, putting 
> symbolic
> links in directories, or some such), but aside from the fact that 
> that's
> a pain and ugly, it doesn't solve the more general problem; if header
> files are supposed to be in Frameworks directories (for example, I
> found my Tk header files in /Library/Frameworks/Tk.framework/Headers),
> what is the best way to set up OS X so that they will be available to 
> link
> against? Note that I don't know that these headers are supposed to be
> there; they just are, and for the time being, I'm assuming that the
> person who put together Tk.Framework knew what they were doing.

Short answer:  Whatever you're trying to build is DOING IT WRONG by not 
using tclConfig.sh (they should allow the user to choose which one, but 
should default to /usr/lib/tclConfig.sh I guess).  This is equivalent 
to not using distutils.  It probably won't be a problem in the Mac OS X 
future however, because...

Apple's latest strategy for unixy stuff (at least for Python) seems to 
be a hybrid approach that should please almost anyone:
	(1) the actual dylib lives in /usr/lib and has a mach-o id pointing to 
/usr/lib
	(2) the framework has symlinks to /usr/lib for its dylib
	(3) the headers live in the framework
	(4) /usr/include has appropriate symlinks into the framework

[I can say this without breaking NDA because Apple has publicly 
released their sources for Python in Darwin 8.0.0b1]

> I also have a more general (and much less important) question relating
> to this, purely for my own interest. Why (on all systems, not just on 
> OS X)
> do we still have to go through this annoyance (and occasionally, 
> nightmare)
> of requiring access to header sources, in order to link against 
> existing
> binaries? Why not simply have the binaries contain all of the 
> information
> necessary to perform the linking? Is this simply a historical holdover 
> from
> the fact that it wasn't done that way originally (probably for good 
> reasons
> at the time), and its too much trouble to change, or are there valid 
> reasons
> for not doing this still? In some sense, putting headers into a 
> Frameworks
> structure is an attempt to include that information a part of a package
> wrapping the libraries of interest; it seems to me that it would make a
> lot more sense (from a design point of view, at least) to include that 
> info
> in the library binary files themselves.

I think that putting the headers in the framework makes more sense.  
Putting it in the binary would be a major pain in the ass for the 
compiler, linker, etc.  Would you rather have an arbitrary per-platform 
binary format (like resource forks and whatever the hell windows does 
to get resources in its exes and dlls), or an easy to create and 
dissect cross-platform "opaque" directory structure (frameworks)?  From 
experience, the latter is WAY easier to live with.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040713/d9862e15/smime-0001.bin