Re: [Distutils] distutils & Borland's free compiler
Excellent! Please do it! I assume you are aware that the starting point is msvccompiler.py; let me just *strongly* encourage you to refactor common code out of the MSVCCompiler class and whatever-you-write (BorlandCCompiler?) rather than submitting a patch with lots of overlapping code.
Maybe I need to double-check the architecture of the distutils with you. It appeared that I (basically) needed to do two things:
1. Create a new class (I was calling it BCPPCompiler, but I'm not too attached to that name ;) which is derived from CCompiler. This class lives in its own module file "bcppcompiler.py" so that it is on the same footing as "msvccompiler.py" (which supports that other company's compiler).
2. Patch distutils/ccompiler.py to add this new compiler into the compiler_class dictionary.
3. Ask Greg about how to let the end-user actually override the default compiler choice for platform "nt". This could be done by passing the keyword argument compiler=bcpp to the new_compiler() factory function, if we had some kind of commmand-line option to let the user do that...
Three! Three things!
Lyle
On 08 May 2000, Lyle Johnson said:
- Create a new class (I was calling it BCPPCompiler, but I'm not too attached to that name ;) which is derived from CCompiler. This class lives in its own module file "bcppcompiler.py" so that it is on the same footing as "msvccompiler.py" (which supports that other company's compiler).
Yeah, you've got the basic idea right. I just suspect that there will be overlapping functionality between the two DOS/Windows compilers, and I would like to see that factored out into a common base class. I went to a lot of trouble a month or two back to factor out the commonality between DOS/Windows (MSVCCompiler) and Unix into the CCompiler base class, and I want others to share the pain. ;-) Err, no, that's not it -- I want to avoid excessive code bloat, and refactoring common functionality is one good way to do that.
The BCPPCompiler name is at least consistent with MSVCCompiler. I guess I didn't spell out MicrosoftCCompiler because I didn't want to utter the vile name in public -- a common superstition among primitive peoples, you know, the strong fear of uttering the enemy's name... ;-)
- Patch distutils/ccompiler.py to add this new compiler into the compiler_class dictionary.
Yup.
- Ask Greg about how to let the end-user actually override the default compiler choice for platform "nt". This could be done by passing the keyword argument compiler=bcpp to the new_compiler() factory function, if we had some kind of commmand-line option to let the user do that...
Hmmm. Good question. This'll be relevant for Mac OS too, as there will -- I hope! -- be two compilers support there.
I think your keyword argument is half the solution; the other half would be a "--compiler=bcpp" command-line option to "build_ext". Go ahead and add that if you feel comfortable doing so.
I will have to hang my head in shame, though, when I see "default: msvc" in the help string. Ahh well, at least it won't say "default: microsoft". (Auugh! my soul was just stolen!)
Three! Three things!
...and a FANATICAL devotion to the pope!
Greg
participants (2)
-
Greg Ward -
Lyle Johnson