Subject: Re: Cygwin 2.1 and Python modules
From: "David Abrahams" <[email-masked]>
To: "Jason Tishler" <[email-masked]>
Cc: "Cygwin" <[email-masked]>
Date: Thu, 5 Jul 2001 10:58:56 -0400

----- Original Message -----
From: "Jason Tishler" <[email-masked]>

> Dave,
>
> Please post to [email-masked] instead of sending private
> email so others can benefit too.  As an added incentive, you may get a
> better response time -- those pesky holidays and vacations are always
> getting in the way... :,)

Sorry Jason. I know how you feel; I get lots of similar private emails at
boost :-(

> On Sun, Jul 01, 2001 at 04:50:42PM -0400, David Abrahams wrote:
> > We corresponded about 9 months ago when I was trying to build python
modules
> > with Cygwin. I've finally managed to figure most of it out, and got
> > something to work. Unfortunately, it required recompiling Python with
> > Cygwin.
>
> Have you tried the pre-built Cygwin Python 2.1 that is part of the
> Cygwin distribution now?

No, but I wouldn't expect it to be any different from what I built.

> > Actually, I have no serious problem with that, but the Cygwin
> > version of Python uses unix path parsing conventions, so PYTHONPATH
doesn't
> > work as the platform expects.
>
> By the above, do you mean how Windows expects?  If so, what is the
> issue?  Cygwin Python understands a Posix style PYTHONPATH.  Are you
> trying to have Win32 and Cygwin Python use the same PYTHONPATH?

Yes.

> Why are you using PYTHONPATH in the first place?  Just install your
> extensions in /usr/lib/python2.1/site-packages and Cygwin Python will
> automatically find them.

See below

> > I'm testing the resulting python modules in a
> > multi-compiler build system, and trying to deal with invoking a
different
> > python executable with a differently-formed PYTHONPATH is just way more
than
> > I'm willing to to invest.
>
> Really?  This is exactly what we do for Java's CLASSPATH on Solaris,
> Linux, and Windows (i.e., Cygwin).  A couple of strategic cygpath's,
> one in the build and one in the startup script, does the trick.
> Using cygpath seems to be *much* easier than trying to build a custom
> Python for Windows.

I don't know what cygpath is. Hmm, looks like a kind of path-translation
tool, but there's no manual entry for it.

I am running everything through a automated build-and-test system which uses
Jam. With one command I can build modules with multiple compilers and build
variants (debug, release...) and test them all using doctest. to run a test,
I need to get the module(s) being tested into the PYTHONPATH. If I was only
trying to do one compiler per command invocation, it would be simple to
munge the PYTHONPATH setting parameters appropriately (I currently do that
once globally, depending on which OS you're running on), but having to
switch it per-compiler would be difficult. It's already painful to select a
different python executable in that case.

> > I tried to rebuild Python with -mno-cygwin,
> > thinking that it might make me a MINGW version which respected Win32
> > conventions, but the build failed in posixmodule.c.
>
> The above is guaranteed to fail since Mingw does not provide the Posix
> functionality that Cygwin does.

Yeah; I was just hoping that configure would detect that it was a non-posix
platform in that case, and not try to include posixmodule.

> > I tried using the
> > pexports utility to extract a cygwin-compatible import library from
> > python20.dll, but the resulting modules crashed miserably.
>
> The above is usually done to build straight Win32 extension modules with
> Mingw or Cygwin -mno-cygwin -- not to build Cygwin extension modules.

Oh! So if I built my extension modules with -mno-cygwin and used pexports to
generate the import library, you think I might be able to link with the
regular Windows Python release?

> BTW, why are you still using Python 2.0 since 2.1 was released months
> ago?

Lots of people haven't upgraded yet. I am just testing Boost.Python for
backward compatibility with Python 2.0.

-Dave

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/