building c extensions with setuptools that are not tied to python installed on build machine

[Ned Deily]

In article 
<CAJv6nDPHGinODQq1Fkh1-uBcYzq2CHag7QJxsbQ0_pHT5z8EQQ at mail.gmail.com>,
 Matthew Taylor <matt at numenta.org> wrote:
> Does this make sense to anyone? I'm still a little new to Python in
> general (especially binary packaging), and it seems like this would be
> a common problem for any projects with C extensions that need broad
> binary distribution. Does anyone have any suggestions? Please take a
> look at our setup.py file [4] and tell me if we're doing something
> egregiously wrong.

Just taking a quick look at your setup.py there shows a quite 
complicated build, including SWIG.  One suggestion: keep in mind that 
it's normal on OS X for the absolute path of shared libraries and 
frameworks to be embedded in the linked binaries, including the C (or 
C++) extension module bundles (.so files) built for Python packages.  If 
any of the .so files or any other binary artifacts (executables, shared 
libraries) created by your package are linked to the Python 
interpreter's shared library, that may be why you are getting a mixture 
of Python instances.  One way to check for this is to use:

otool -L *.so *.dylib

on all of the directories containing linked binaries in your project and 
check for paths like:
/System/Library/Frameworks/Python.framework 

That would be a link to the Apple-supplied system Python.

A link to /Library/Frameworks/Python.framework or some other path would 
be to a third-party Python like from python.org or Homebrew.

Due to differences in how the various Pythons are built and depending on 
what the C or C++ code is doing, it may not be possible to have one 
binary wheel that works with different Python instances of the same 
version.  For many simple projects, it does work.

You *could* also ask on the PythonMac SIG list.

https://mail.python.org/mailman/listinfo/pythonmac-sig

-- 
 Ned Deily,
 nad at acm.org