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.