[C++-sig] Building boost.python on Mac OS X

[Bob Ippolito]

On Friday, Sep 12, 2003, at 21:36 America/New_York, Ralf W. 
Grosse-Kunstleve wrote:

>> Thanks for these pointers.  Based on that information and your public
>> build logs, I was able to build and link libboost_python.dylib and our
>> extension module against a non-framework installation of Python2.3.
>
> Wow! That's very interesting.
> Did you try using /usr/bin/python?
> Now I am beginning to wonder if it is better to work with a framework 
> or a
> non-framework build. I am not an Apple user. Could someone more 
> experienced
> with OS X name some pros and cons?

Frameworks are nicer to work with than libraries because they put 
everything in one place.  They're "opaque directory structures", or 
Bundles.. For example, in a typical unix application, when you install 
a library:
	the library goes in /usr/local/lib
	the headers go in /usr/local/include
	its resources go in... who knows, /usr/local/share maybe?  it depends.
	they have no metadata.

With a framework:
	the framework goes in /Library/Frameworks (as frameworkName.framework)
		the headers go in the framework.. /Headers
		the library goes in the framework.. frameworkName
		its resources go in the framework.. /Resources	
	Frameworks also have metadata associated with them in a plist file 
(xml or NeXT style property list)

It's nice for organization.  In gcc on OS X, if you say #include 
<frameworkName/someFrameworkHeader.h> you don't even need an 
-I/Library/Frameworks/frameworkName/Headers as a linker flag.  It just 
knows where to find it.  Also, when you're linking, instead of 
-lsomelibrary you just say -framework frameworkName.

There's also more than one place you can put frameworks, 
/Library/Frameworks, ~/Library/Frameworks, 
@executable_path/../Frameworks, etc.  @executable_path is a special 
thing in a mach-o header that lets you reference dynamic libraries 
inside an application bundle.

Frameworks can also do lots of things with regard to versioning.  For 
example, you may not know this, but you probably have 3 versions of the 
Foundation framework installed, so that older applications that link to 
an older version will find it just fine.

That said, they're merely for consistency and organization.. They're 
great, and I recommend them, but they don't do much for you 
*technically*.  A dylib is a dylib, and frameworks use dylibs.  There 
is nothing super special about them as far as linking is concerned, and 
they don't get any super special features (other than the features that 
bundles give you.. really easy localization, easy to move around, stuff 
like that, but that's mostly at the application level).

It is better to work with a framework build if you have one, but 
distutils fully support frameworks yet so you will have to tweak things 
if your python module links to other frameworks.

-bob