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 -- http://mail.python.org/mailman/listinfo/python-list