[C++-sig] Building boost.python on Mac OS X
bob at redivi.com
Sat Sep 13 04:15:32 CEST 2003
On Friday, Sep 12, 2003, at 21:36 America/New_York, Ralf W.
>> 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
> 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
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,
@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.
More information about the Cplusplus-sig