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.