Lets say I want to use gcc
from the command line in order to compile a C extension of Python. I'd structure the call something like this:
gcc -o applesauce.pyd -I C:/Python35/include -L C:/Python35/libs -l python35 applesauce.c
I noticed that the -I
, -L
, and -l
options are absolutely necessary, or else you will get an error that looks something like this. These commands tell gcc where to look for the headers (-I
), where to look for the static libraries (-L
), and which static library to actually use (python35
, which actually translates to libpython35.a
).
Now, this is obviously really easy to get the libs
and include
directories if its your machine, as they never change if you don't want them to. However, I was writing a program that calls gcc
from the command line, that other people will be using. The line where this call occurs looks something like this:
from subprocess import call
import sys
filename = applesauce.c
include_directory = os.path.join(sys.exec_prefix, 'include')
libs_directory = os.path.join(sys.exec_prefix, 'libs')
call(['gcc', ..., '-I', include_direcory, '-L', libs_directory, ...])
Instead, I need a solution from within Python that will reliably return the include
and libs
directories.
I looked at the module distutils.ccompiler
, and found many useful functions that would in part use distutils, but make it customizable for me to make my compiler entirely cross platform. The only thing is, I need to pass it the include and runtime libraries...
I looked at distutils.sysconfig
an I am able to reliably return the 'include' directory including all the header files. I still have no idea how to get the runtime library.
The distutils.ccompiler
docs are here
The program that needs this functionality is named Cyther
The easiest way to compile extensions is to use distutils
, like this;
from distutils.core import setup
from distutils.extension import Extension
setup(name='foobar',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
)
Keep in mind that compared to unix/linux, compiling extensions on ms-windows is not straightforward because different versions of the ms compiler are tightly coupled with the corresponding C library. So on ms-windows you have to compile extensions for Python x.y with the same compiler that Python x.y was compiled with. This means using old and unsupported tools for e.g. Python 2.7, 3.3 and 3.4. The situation is changing (part 1, part 2) with Python 3.5.
Edit:
Having looked in the problem more, I doubt that what you want is 100% achievable. Given that the tools needed for compiling and linking are by definition outside of Python and that they are not even necessarily the tools that Python was compiled with, the information in sys
and sysconfig
is not guaranteed to an accurate representation of the system that Python is actually installed on. E.g. most ms-windows machines will not have developer tools installed. And even on POSIX platforms there can be a difference between the installed C compiler and the compiler that built Python especially when it is installed as a binary package.
If you look at the source of build_ext.py
from distutils
in the method finalize_options
you will find code for different platforms used to locate libs.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With