[Distutils] Questions about distutils strategy

[Tim Peters]

[Tim]
> ...
> Goodness, you can even use the DevStudio Build -> Start Debug ->
> Attach to Process ... menu item to start debugging an arbitrary
> process already running on the system, source code or not,
> originally in a DevStudio language or not.

[James C. Ahlstrom]
> Very interesting.  I didn't know that.  Probably neither
> does the average Windows developer.

They don't need to know it.  I was explaining an extreme.  In normal usage,
the worst that's required is that you open the .exe you want to debug from
within DevStudio and click "Go".

>> If it wasn't compiled with MS-style symbol info, though, you
>> can't do much more than step thru the machine code.

> Ooops, not at all what people will want.

Again explaining an extreme.  If you use MS's compiler to compile your stuff
from a cmdline, you get MS-style symbol info, and debugging is the same as
if you had compiled it using DevStudio (DevStudio compilation is just a
massive GUI around a cmdline compiler & linker!).  Of *course* MS's debugger
doesn't understand non-MS symbol info, any more than gdb understands MS's
style.  So don't do that <wink>.

>> Notwithstanding, many hardcore Windows weenies *prefer* doing
>> development under DevStudio.  But I'd say that's a topic for
>> the DevUtils SIG <wink>.

> I think we may be kidding ourselves.  It is not a matter of "prefer".

Sure it is.  DevStudio also has a menu entry to generate a makefile (of MS's
odd nmake flavor).  I often set up personal projects using DevStudio, and
then switch to a generated makefile so I can run overnight builds and tests
from .bat scripts.

> Distutils is not at all compatible with DevStudio.  Suppose you
> add a file to the project in DevStudio.  You will have to make
> the parallel change by hand in Distutils.  People use (or should
> use) _ASSERT(), so there must be Debug and Release versions no
> matter if the debugger is used or not.  Built in to DevStudio,
> a file edit (at best) in Distutils.

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.

> And to top it off, you need on-line documentation for Windows
> anyway, so you need DevStudio or equivalant even if you do
> learn Distutils.

Sorry, but I don't understand where this is coming from.  As a Windows
Python Guy, I have one of five scenarios in mind for "distribution":

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.

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.

3) The audience is Python programmers "in general", or the audience is me,
and the product is a C extension module.  This is where I expect to use
Distutils, and hope that others do too.  An MS project file doesn't do my
Unix friends any good, any more than their fiddly platform-dependent gmake
files help me, and binaries suck for similar reasons.  Most interesting
extension modules I've seen have been written by Unix weenies -- and *when
you're lucky* their home page has a contributed Windows .pyd just two
releases out of date <wink/frown>.

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.

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>.

> People in PythonDev[:] may put up with this, but if we go to
> main-stream Windows developers and say "do this our way" they
> will say "no thanks".

Main-stream Windows developers have no way at all to distribute a x-platform
app now, so their choice is between "our way" and "no way".  If they're not
interested in x-platform distribution, I indeed don't see what Distutils
*could* offer them in the way of helpful code (except in case #4 above --
where compilation (& so also DevStudio) isn't an issue).

> Distutils makes sense on Unix where things are done with
> makefiles.  Why do we even care if Windows developers make
> Python extensions in DevStudio?

I don't care at all, provided they have no interest in sharing their work
with non-Windows people.  If they do want to share, they need to do more
work (their Windows binaries aren't going to run on a SPARC <wink>), and
Distutils can help with that.

life-will-be-simpler-when-windows-is-the-only-os-ly y'rs  - tim