distutils, C extensions, Borland compiler, wxPython

[Anders J. Munch]

"Michael Hudson" <mwh at python.net> wrote in message
news:ulme8ovdf.fsf at python.net...
> "Anders J. Munch" <andersjm at dancontrol.dk> writes:
>
> > I have built Python from source on Win2K using cygwin except with a
> > Borland compiler (BCB4) instead of gcc.  It took a fair amount of
> > hacks to get the configure script and makefiles to work (s/.o/.obj/ is
> > just the beginning) but it was worth it.
>
> Which version of Python?  I thought there was at least *some* support
> for this in recent versions of python.

I began with a not-so-recent version. When I had the choice I
preferred wrestling with the vaxocentrisms of the main build mechanism
over wrestling with the MSVC++'isms in the PC subdirectory. Seemed
like the right thing to do.

Currently using 2.2.

>
> Have you looked at google to see if people have tried this before?

Yes.  I don't like to reinvent the wheel, but in this case all the
wheels I could find were square.

> Try using
>
> $ python setup.py build --compiler=bcpp install
>
[...]
>
> Hopefully the author of ../distutils/bccpcompiler.py has done the
> messing already...

It's worth looking into.  I presume the bcpp code is written with
interfacing an MSVC++ Python build in mind.  Perhaps I can patch it.

>
> > and also my python.exe is not a cygwin app. and hence doesn't
> > understand the cygwin paths from the make process.
>
> Don't really follow you here, but as I've never used the borland
> compiler and try to avoid understanding windows issues...

Let me illustrate by example.

bash is cygwin-enabled:
  $ ls /usr/local/lib
  python2.2

In native cmd.exe the same directory is called something else:
  C:\>dir /b c:\cygwin\usr\local\lib
  python2.2

But cmd.exe, like my python.exe, isn't cygwin-enabled:
  C:\>dir /usr/local/lib
  Invalid switch - "usr".

  C:\>dir \usr\local\lib
  The system cannot find the path specified.

>
> > Now what I'd like to have is for distutils to just tell me which
> > .c/.c++ files need to be compiled into python and with which options,
> > so that I could add these files to Setup.local manually and rebuild
> > python.exe.
>
> This *shouldn't* be that hard; the setup.py file should contain a list
> of source files that need compiling, like
>
> setup(...
>       extensions = [Extension("wx", ["wxfile1.c", "wxfile2.c"]),
>         ...]
>       ...)
>
> this translates to lines in Setup.local along the lines of
>
> wx wxfile1.c wxfile2.c

I've taken this path before with simpler stuff, but the problem is
that I'll miss out on whatever clever stuff the setup script does in
addition to running distutils.core.setup.  E.g. the wxPython setup
will run SWIG to generate .c files on the fly if you ask it to.

Maybe that's what I'll end up doing -- I probably will be able to
decipher wxPythons setup script and emulate it -- but I was hoping to
come up with a procedure that didn't require me to reverse-engineer
the setup script for every package with C extensions that I install.

> > Are there any docs on how to tell distutils which compiler to use
> > and how?
>
> There's
>
> http://python.sourceforge.net/devel-docs/inst/inst.html

The "Borland C++" section begins by saying "Python is built with
Microsoft Visual C++".  Non sequitur.

>
> but I don't know how thorough this is -- I generally read the source
> when I need to understand what distutils is up to...

320079 bytes of source code and no overview document.  Even Python can
be a write-only language if the code is large enough and there's no
way of getting the big picture.

- Anders