[Distutils] Contemplating upheaval in CCompiler API

Greg Ward gward@python.net
Tue, 30 May 2000 20:42:56 -0400


Hi all (especially to the two [?] of you working on support for
additional C/C++ compilers) --

I'm contemplating a major simplification in the CCompiler API that
should make life easier for anyone writing or maintaining one of the
CCompiler classes, but will raise a lot of dust for a few days.

Specifically: currently, each of the compile/link/whatever methods takes 
a bunch of arguments that enhance instance attributes.  For example,
every CCompiler instance carries around attributes 'include_dirs',
'libraries', and 'library_dirs'; plus, the 'compile()' method takes an
'include_dirs' parameter, and the 'link_*()' methods all take
'libraries' and 'library_dirs' parameters.

These are all combined by convenience functions provided by the
CCompiler superclass, so the code overhead to supporting this rather
complex interface isn't *too* great.  However, I'm getting tired of the
*conceptual* overhead: you're forever worrying about "instance attribute
'include_dirs' vs. method argument 'include_dirs'", and so forth.

So I'd like to ditch all the extra method parameters and rely on
instance attributes as much as possible.  That moves CCompiler a little
closer to representing a "compiler/linker session", which is meaningless
in Unixworld but very much relevant in Macland.  (Or so I gather from my
spies in that strange and distant country.  I'm not clear on the
situation in Windowsia, given the constant turmoil in that troubled
realm.)  I think this is a good thing.

The main drawback is that it would make the "build_ext" command a bit
more complex.  Currently, it sets the instance attributes for
compilation properties that apply to all extensions, and passes method
arguments for things that vary by extension.  (Currently, only
'include_dirs' can do both.)  It would have to take care of combining
the "global" and "per-extension" properties when it starts to build each
extension.  This is not, IMHO, a big deal.

If nothing else, it would make the signatures and docstrings for the
common CCompiler methods a *lot* shorter.  Opinions?

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
Screw up your courage!  You've screwed up everything else.