First of all let me apologize for the problems we have been
seeing with the binaries as of late. Frankly the root of the problem
might be my detachment from the matplotlib source for some time.
Unfortunately due to my time constraints, this won’t be changing soon.
I used to think being somewhat on the outside helped me keep the ease
of the build process in check. This gap has apparently grown too
I appreciate that this is a difficult task and that you have plenty of other responsibilities, and appreciate your effort. However, I’ve been trying to get to the bottom of why the windows installer is overwriting configobj and I could use some feedback from you. I really need to know whether you delete the build/ directory before creating a new installer.
Moving ahead, python 2.6 and 3.0 are going to pose new challenges
since they require new versions of visual studio I do not have access
I think 2.6 and 3.0 were both compiled with Visual C++ 2008, and so the free Visual C++ 2008 express can be used to create extension modules. I the past I have built and distributed extension modules built with mingw32 on windows XP, but I have not been able to put together a working mingw32/msys on a 64-bit windows vista machine. This is my only windows computer, so it looks like I will only be supporting py2.6 in the near future.
Doing builds for 4 windows versions poses a great time to work on
a standard cygwin build setup (not that the cygwin build process
doesn’t work as is). In addition to that we are going to possibly be
seeing osx fat binaries with 4 architectures! I am more than happy to
continue to contribute my time to create these builds, but I think it
only makes sense to have a release candidate cycle before formally
pushing to sourceforge.
What are the four architectures? I’d be willing to get things together on my windows install so I can build mpl from source and help test with python-2.6. (I know I’m going to regret this.)
On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cwmoad@…149…> wrote: