- E02 - Support for MinGW Open Source Compiler

[Pat]

Fredrik Lundh wrote:
> "Pat" wrote:
>
> > A few things.  Primarily the fact that I'm not very experienced in
C
> > (the extensions that I need to have compiled are not written by
me).
> > Secondarily, the fact that the discussion threads I read made it
seem
> > much more complicated than what you just described.
>
> from two posts at the top of this thread:
>
>     "Writing a setup.py and running
>         python setup.py build_ext --compiler=mingw32
>     works for me *without* any more work. Things can't get much
>     simpler."
>
> and
>
>     "The mingw compiler *is* supported through distutils. distutils
>     can straightforwardly be configured to build extensions with
>     mingw."

In my defense, the threads I was referring to were prior to this thread
and did not include the two snippets that you've quoted.  Besides,
there *was* additional work that needed to be done, specifically adding
the python23.dll or python24.dll to the \mingw\lib directory, as you
mentioned in one of your previous posts.  Now, I'm not saying any of
this is rocket science, or isn't fairly easy to overcome.  But it is a
definite stumbling block for someone like myself who is less fluent
with C that you are.

> (now go read Ilias replies to those posts)

I'm not Ilias.  He'll have to fend for himself.  I just happen to have
a similar need to understand how to simplify the process of compiling
extensions for Python in light of the recent changes with Python 2.4.

> > Third, the fact that some of the code we've tried to compile didn't
compile
> > cleanly, the way your cElementTree did (but I can't remember what
exactly
> > the problem was and I didn't do the compiling).
>
> was that code tested under gcc?  code that compiles under visual C
doesn't
> necessarily compile silently under gcc, but fixing that is usually
pretty trivial
> (no worse than porting mostly portable code between platforms).

The code was not written by me.  Specifically, we are making use of
PEAK and the "unofficial" GPL port of Qt for Windows (not the upcoming
GPL version from Trolltech).  I just want it to work.  ;-)

> > And, finally, an aversion to trial-and-error solutions.  I prefer
to Google and
> > ask questions when I'm out of my element.
>
> sure didn't sound that way when you entered this thread:
>
>     "So in an effort to make some headway, I'm going to try to
summarize the
>     current state of affairs.  The bottom line is that compiling C
extension modules
>     on the Windows platform for Python 2.4 is, today, a royal pain in
the ass.
>     Period.  Here's why. /.../"

Okay, I suppose I could have done a better job phrasing that.  I should
have said something like "in my personal opinion, finding definitive,
documented information on the proper way to compile C extensions for
Python in light of the recent changes to Python 2.4 is a royal pain in
the ass."  To that I would now add "But Fredrik Lundh thinks things
can't get much simpler, and if you ask him nicely he'll show you the
error of your ways."  ;-)

> now go download MinGW and figure out what's wrong with your C code.

It isn't my C code.  I'm only including it as a dependency in my
project and trying to make the use of it by my users "simpler than
could ever be conceived by someone who thinks things can't get much
simpler".  ;-)

> if you get stuck, post the error messages, and I'm sure some
c.l.pythoneer
> will help you sort it out.

Thanks.  In all seriousness, you're posts have helped.  When we ran
into snags we tried to compile cElementTree, got a bunch of errors,
figured out we hadn't copied python23.dll into /mingw/lib, and were
able to compile everything we needed.  We still haven't tried that for
Python 2.4 yet, due to other constraints that we haven't worked out.
But I think we are getting closer and your help is greatly appreciated.
 :-)

--
Patrick K. O'Brien
Orbtech    http://www.orbtech.com
Schevo     http://www.schevo.org
Pypersyst  http://www.pypersyst.org