Hello,
I've been following the discussion on how to build C (or C++, or other
languages) extensions with interest. I'm thus talking about the
'build_extensions' command of the proposed interface, if I understand it
well.
Some talk has gone into reading a lot of low level Autoconf results into
Python, and exposing them through a sysconfig module. Some objections
were raised that this was rather low level.
It's also not very portable, right? Options that go into gcc won't make
much sense for Visual C++, I imagine.
Now, we could try to abstract a compiler framework in Python. I
understand this is what John Skaller is working on, but I may be wrong
as I haven't looked yet.
Abstracting a compiler with its myriads of options could be a pain. We
might end up having to abstract makefiles as well in Python. And
building C libraries. This could be a rather big project. We'd be
duplicating a lot of stuff, as well.
I'm not too keen on simply calling 'make' directly from our builder
script either, though. That's rather tied to the platform.
So let's try abstracting some more. See if it becomes any simpler. I
think this is what other people might've proposed as well, and if so,
I'm just saying 'me too', here.
I'll sketch out a very simplistic and anarchic high level interface
here.
The base class:
class extension_compiler:
def compile_C(filename):
pass
def compile_C++(filename):
pass
That's about it, unless we want to choose to support more extension
languages by default.
For each platform we want to support, we supply a subclass of this.
For example:
class gcc_extension_compiler(extension_compiler):
def compile_C(filename):
os.system("gcc -c " + filename)
def compile_C++(filename):
os.system("gcc -c " + filename)
That's just about all. We don't have any fancy options (though we might
want to enable optimizations by default).
But what about special optimizations, debugging, profiling, other fancy
stuff? Our abstraction doesn't support this! We need more methods. We
need set_optimization_level(10)!
Do we? Who does?
Generally, only the extension developer knows which special compiler
options could work best with the extension code. The extension writer
only knows this for his platform(s) of choice, too. Extensions should
still build cleanly for anyone on any platform. Thus we do best with as
abstract an interface as possible.
The extension builder should be given the option to subclass, and
provide special compilation options for optimization purposes. Profiling
and debugging builds are generally only necessary for the extension
developer, and could be handled by special throw-away subclasses. If the
developer has figured out how to make extensions build best and fastest
on Linux, he can always include a special purpose
linux_extension_compiler subclass which calls the compiler with special
optimization options.
If later it turns out we do need special option settings (for all
compilers on all platforms!), we can always add it later.
Anyway, I'm leaving lots of stuff out here. We probably need to do the
same simplistic abstraction to the linker.
The emphasis is to keep the interface as small as possible. A large
interface means supporting it on all kinds of different platforms, and
that is a lot of work. Once we got a small basic interface going, we can
always extend it, platform by platform, with more options, if necessary.
A simple 'RISC' interface does limit developers. They can't do all kinds
of fancy makefile stuff they usually do. But we don't want to have to
support all the fancy makefile stuff anyway.
....remembers ./configure ./make and why the complicated ./configure
step is there in the first place; to enhance portability. Hm. *ponder*
Okay. Perhaps that invalidates my entire argument above. It might be
that I'm limiting developers from using any external libraries in their
extensions.
Still, philosophically, I think my arguments are sound. In practice,
however...
Leaving-confused-ly yours,
Martijn
