However, some stuff that should be trivial is tricky (the most frustrating thing is trying to copy files to a build directory -- it installs stuff to the prefix path without a problem, but intermediate copies don't work well at all). I've gone over the fooling around needed to get boost.python to work with MacPorts, but one would expect CMake (since its configuration allows the manual selection of most compilers, libraries, etc.) to handle it without a problem. Sadly, though, when using the FindPythonLibs module and FindSWIG and UseSWIG, it defaults to linking against the Python framework found in
/System/Library. I spent probably a few hours googling for a solution, but finally today I found one that works without any hacks at all.
The key is that on Mac OS X systems, rather than looking for headers and libraries, FindPython prefers to search for the Python framework. There are several locations it checks in some preferential order. All that needs to be done is to symlink the Python framework installed by MacPorts to one of the higher-preference locations:
ln -s /opt/local/Library/Frameworks/Python.framework /Library/Frameworks/
Ta-da, now running
otool -Lon the SWIG modules that CMake generates properly shows that they link against the MacPorts framework, and the right include and library paths are used.