[Distutils] bdist and --compiler

[Greg Ward]

On 23 May 2000, Rene Liebscher said:
> First the system seems to check the filedates
> with the objectfile-extensions of the standard compiler
> ( msvc ".obj" , cygwin ".o" ). So it doesn't find my
> object files, and tries to recreate them, but uses a
> wrong compiler. I think it should be
> possible to configure the compiler also for "bdist".

See Thomas' reply, and my reply to him, for one way of doing it.

> (If this is already possible? Please explain how.)
> Also I think "bdist" does a "build" if there aren't
> already the right files. In this case "bdist" should 
> accept *all* parameters which "build" accepts.

The trouble with that is that lots of commands run other commands.
Currently there's very little formal notion of "sub-commands" -- if
command X wants to replicate an option from command Y, it has to be done
manually.  This is deliberate design minimalism; the idea is to keep
each command's scope under control.

Of course, that leads to awkward command lines.  Hence, config files.
If you're running last night's code ("cvs update" -- it's your friend!), 
try this: create "<prefix>/pydistutils.cfg" (on Windows and Mac OS --
it's different for Unix) and put the following in it

[build_ext]
compiler=cygwin

and then you never have to worry about specifying the compiler again:
it's a system default.

Of course, be sure to read all the debugging output that is deliberately
still in the code: I want everyone to share the pain!  

> The second problem. Why "bdist" doesn't check only the
> source files against the finished extension modules?
> Currently it seems to check the source files against
> the compiled object files.

Good point, I think.  I'm trying *not* to emulate everything you'd do in
a real Makefile, since Distutils != make.  But this could be a useful
addition, if I understand what you're saying -- I'll have to think about
it.  (Hint: working patches are an excellent way to prod me into
thinking about something.  They also clarify wonderfully what exactly
you're talking about.)

> Then there is something else concerning the compiler
> option.
> If the user uses help he get the information that he
> can use the compiler option, but how can he know 
> which compilers(classes) are available. There should be 
> a possibility to get a list. (In ccompiler.py we have 
> such list, we only had print it.)

That's definitely a good idea.  Wasn't such a big deal in the "old
days", when we only had UnixCCompiler and MSVCCompiler.  Those days
appear numbered, though...

How does a "--help-compilers" global option sound?  (Kind of on the same
level as "--help-commands".)  It's a bit klugey, but I can't think of a
better option offhand.

        Greg
-- 
Greg Ward - programmer-at-large                         gward@python.net
http://starship.python.net/~gward/
Heisenberg may have slept here.