Following [this recommendation](https://stackoverflow.com/questions/1942298/wrapping-a-c-library-in-python-c-cython-or-ctypes), I have written a native C extension library to optimise part of a Python module via ctypes. I chose ctypes over writing a CPython-native library because it was quicker and easier (just a few functions with all tight loops inside).

I've now hit a snag. If I want my work to be easily installable using distutils using `python setup.py install`, then distutils needs to be able to build my shared library and install it (presumably into `/usr/lib/*myproject*`). However, this not a Python extension module, and so as far as I can tell, distutils cannot do this.

I've found a few references to people other people with this problem:

* [Someone on numpy-discussion with a hack back in 2006](http://mail.scipy.org/pipermail/numpy-discussion/2006-August/009928.html).
* [Somebody asking on distutils-sig and not getting an answer](http://mail.python.org/pipermail/distutils-sig/2008-July/009654.html).
* [Somebody asking on the main python list and being pointed to the innards of an existing project](http://mail.python.org/pipermail/python-list/2007-January/473170.html).

I am aware that I can do something native and not use distutils for the shared library, or indeed use my distribution's packaging system. My concern is that this will limit usability as not everyone will be able to install it easily.

So my question is: what is the current best way of distributing a shared library with distutils that will be used by ctypes but otherwise is OS-native and not a Python extension module?

Feel free to answer with one of the hacks linked to above if you can expand on it and justify why that is the best way. If there is nothing better, at least all the information will be in one place.