SourceForge logo
SourceForge logo
Menu

Re: [matplotlib-devel] Binary release process

From: Charlie M. <cw...@gm...> - 2008年12月14日 18:58:23
On Sun, Dec 14, 2008 at 1:22 PM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Dec 14, 2008 at 12:24 PM, Charlie Moad <cw...@gm...> wrote:
>>
>> 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
>> wide.
>
> 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.
I don't have my build directories anymore, but they were made from
extracting the source release so there was no previous build
directory. It is possible that I missed those settings in setup.cfg,
because I do not have either of those module installed.
>
>>
>> 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
>> to.
>
> 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.
>
Good to know there is a free option.
>>
>> 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.)
>
"32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and 64-bit x86"
http://en.wikipedia.org/wiki/Fat_binary

View entire thread

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /