spe for Python 2.7? -> getting closure on a patch

[Dave Curtis]

I'd like to wrap up a committable patch for SPE for Python 2.7 before I forget what I was doing.

The issue as I see it is: What is the correct way to handle the architecture build flags?

It seems clear that 'supported_archs i386 ppc' should be set.

The ugly thing is what to do about the python call site in SPE -- I'm currently running with a patch that calls Python via 'arch -i386'.  The good news is that my build seems to be functionally rock solid, I've been using it heavily for a few days.  The bad news is that it generates outrageous amounts of chatter on stderr -- I'm not sure where all the warnings are coming from, but I suspect they have their roots in wx.  I don't have the time to chase them down, and I don't have the background with wx to be very effective at it.  Since SPE seems to have excellent stability despite the console noise, I'd like to leave it as-is.

Unfortunately, my 'invoke Python via arch i386' patch will break on PPC.  Ryan suggests below that one way to fix this is to turn off the universal variant.  That seems to me to be the best solution -- are there large numbers of people that will care about having an i386/ppc universal build of SPE?  I'm guessing not.

If that is what we want, then I have two questions:
1. How do I make a patch conditional on the build variant?
2. How do I turn off universal?

-dave

On Mar 23, 2012, at 2:40 PM, Ryan Schmidt wrote:

> 
> On Mar 23, 2012, at 15:42, Dave Curtis wrote:
> 
>> 
>> On Mar 23, 2012, at 1:00 PM, Ryan Schmidt wrote:
>> 
>>> On Mar 23, 2012, at 01:46, Dave Curtis wrote:
>>> 
>>>> 2. added supported_arches i386 because of wx dependency
>>> 
>>>> 4. tweaked call to python to use arch -i386, which was conveniently already being patched in the portfile.  This was moved to a post-patch to get out of the way of a new patchfile.
>>> 
>>> These changes will break spe for users on PowerPC Macs.
>> 
>> so...
>> 
>> supported_arches i386 ppc
>> would be correct for #2, right?
> 
> supported_archs, but yes, that would match what's in the wxWidgets port.
> 
> It's not clear to me why py27-wxpython is always 32-bit whereas py26-wxpython is 32-bit only in its carbon variant; that's weird. But the wxWidgets situation in MacPorts and in general is so confusing that I don't feel like figuring it out. Somebody should work on integrating the lone py26-wxpython into the existing unified py-wxpython port (which already provides the python 2.4, 2.5, and 2.7 versions). Not sure if this is covered by any of the zillion existing open tickets about wxpython.
> 
> 
>> For #4, would it be correct to choose the patch conditioned on the build arch?  Basically, leave off the 'arch -i386' part of the patch for ppc?
> 
> If we're getting into the business of patching in "arch" commands to run programs under a particular architecture, then I suppose yes. Of course that won't work for the universal variant, so you may have to turn off the universal variant.
> 
> 
>>> 
>>>> 5. Added patchfiles command to overcome the fact that pychecker2 is not available in macports.  spe contains a fall-back version of the module, so I tweaked the installation to include the fallback version.
>>> 
>>> Can we instead get pychecker2 into MacPorts?
>> 
>> I briefly looked around for that, but it's not clear to me where to find the canonical source for pychecker2.   It would be a bit of a research project.  A few minutes of googling turns up discussions from around 2007.  One comment said: "I'm not sure pychecker2 was ever released."   Some tracker activity on Debian from 2007 shows that they considered but then punted and didn't create a pychecker2 package, but just left pychecker2 in spe. Looking in the current package databases for Debian and Arch both show dependencies on pychecker, but neither show dependencies on pychecker2.  Neither contains a pychecker2 package.   So I'm guessing that most distros are just pulling in pychecker2 from spe.  
>> 
>> It looks like spe hasn't had any active development for a couple of years.  It's stable, and I think Stani has moved on to other things.  I don't think pychecker2 will ever be more than a submodule in spe.
> 
> Understood, thanks.
> 
> 
>