On 08 December 1999, Tim Peters said:
The difference between Debug and Release is entirely in switches passed to the compiler and linker; makefiles can handle that fine based on target name (or envars, or anything else a makefile can see; have DevStudio generate a makefile to see how MS does it). As I hope will become clearer soon, though, I don't grasp why any of this is a Distutils issue.
It could be a minor Distutils issue: I've toyed with the idea of "--debug" or "--optimize" flags (or maybe "--release"?) to the 'build_ext' command that would translate to appropriate compiler switches. I know how to do this for the "generic Unix C compiler" implemented by the UnixCCompiler class, but someone else would have to do it it for MSVCCompiler.
1) The audience is purely Windows developers. Then I ship a zip file containing source and an MS project file, and leave Distutils out of it entirely.
Probably appropriate, although in my more megalomaniacal moments I tend to think, "Who needs make? Who needs IDEs? You can do it ALL with Python, a C compiler, and Distutils!" (In an idle moment the other day, I started thinking about a Distutils command to build Perl extensions... I got over it pretty quickly though.)
2) The audience is purely Windows end users. Then I ship pre-compiled binaries, because they can't possibly deal with compilation themselves (they don't have compilers!). In this case I'm not sure whether Distutils can help (it would have to become an Installshield clone to meet expectations); but, ragardless, compilation is again not an issue for distribution.
Creating binary distributions is in the plans, although they'll be called "built distributions" because an RPM that contains only .py (and maybe .pyc) files isn't really "binary". The plan decided on at that fateful Developer's Day session *over a year ago* (wow!) was that we'd figure out something for Windows with WISE Installer (or whatever it's called). I think the theory was that somehow we could write Python code that would magically generate a Windows installer. I certainly haven't done anything about that, although at some point I expect I'll have to walk downstairs and grill Guido about Windows installers for Python until he gives up and tells me to bug someone else. FWIW, the interface I envision is *something* like this: $ ./setup.py bdist --format=rpm [...create a spec file, run rpm -B...] $ ./setup.py bdist --format=wise error: can't create Windows installer under Unix Oops! Let's try that second one again C:\> ./setup.py bdist --format=wise [...somehow magically create a WISE installer...] Hmmm, this is starting to look like yet another argument for system-wide and user-specific config files to supply default values for things like the bdist format. (And, for that matter, the dist format, which can be one of 'gztar', 'ztar', 'tar', or 'zip'.)
4) The audience is Python end-users "in general", and the product is pure Python. I think this is the most important one for Distutils to address, and compilation isn't a part of it. So far, though, what Gordon is doing seems more appropriate than what Distutils has been up to. I hope his work gets folded into this.
Here the distinction between "source distributions" and "build distributions" gets fuzzy. I actually think it's important and worthwhile to provide "built" distributions of pure Python distributions -- not for technical reasons, but for social/political/usability reasons. Eg. if I can install a mixed C/Python distribution from an RPM or a WISE installer, then I should be able to do the same for a pure Python distribution. You and I will know that it's a waste of disk space to offer both versions, and a waste of machine time to have dist-bots churning out pure Python built distributions from source distributions, but it's necessary for a consistent user interface on each platform supported by the "bdist" command. I assume that "what Gordon is doing" is the Python archive stuff? My attitude towards that is the same as it is towards all of these funky new things coming down the pike: interesting, keep an eye on it, maybe try it out if I get a few minutes... *but* Distutils support will have to wait until there is One Standard Way of doing things. The whole point of Distutils is to be the One Standard Way; I certainly don't claim that copying .py files into directories and compiling them to .pyc files is the only way to install Python module distributions, but until these issues (archive format, imputils, etc.) are worked out and finalized then Distutils won't (officially) support them. Of course, I think it would be really cool if competing archive formats were presented to the world with implementations in the form of Distutils command classes, but that's probably my megalomaniacal tendencies coming out again.
5) The audience is Python end-users "in general", and the product is some mix of Python and C extension modules. This is hard. You have to ship binaries to meet Windows expectations; you have to ship source to meet Unixish ones; and the more popular Linux gets, the more the Unix dweebs will be left whining without a clue about the changing nature of their customer base <0.7 wink -- but over on Python-Help the sight of a Linux user who doesn't know how to compile is no longer rare>.
As Guido said on python-dev, a Distutils "appdist" command is probably the answer. Or maybe "appbdist", I dunno. I'm not sure if separate commands are really needed, or if the "build", "install", "dist", and "bdist" commands will grow up to recognize Python applications rather than just module distributions. That's a bit of a ways off, though: I said at the beginning that I want to handle module distributions first, and then worry about applications. Maybe by that time, the "Python archive format", imputils, one-file-Python-distributions, etc. will be more stable. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913