On 10/07/2008, at 2:04 PM, mabshoff wrote:
>> It should be fine. We used UCS2 until maybe 8 months ago. We >> switched >> as mentioned above only for Linux compatibility. >> >>> You will need to do this for each successive >>> version of sage, which could be tedious. >> >> I would be ok with making an environment variable, e.g., SAGE_UCS2 >> that if set causes SAGE to build using UCS2. > > I don't like this at all since it will introduce more complexity and > the possibility for subtle bugs. Only for people who know they set the environment variable and compiled sage themselves. >> Alternatively, we could make Sage on OS X use UCS2 but Sage on >> Linux use UCS4. > > I like this even less since Apple's python is universal and when you > build extensions with it those extensions are universal (or the > compiler at least attempts to build them). My extensions are not universal, though they apparently work with both the universal system python in /usr/bin/python and the non-universal sage and fink pythons. (Obviously I can't move my extension between architectures.) > We will switch to Python 2.6 > at some point and Apple might now follow. What to do then? Maybe their > next universal binary will be four arches instead of two now? As is > the 64 bit Sage port on OSX is fundamentally incompatible with any > python Apple ships. Sure. If it's not easy, don't do it. Also, the python headers I'm using are not matched to the (sage) python binaries, so what I'm doing is somewhat asking for trouble. The options see are * have a UCS2 option in sage python * have UCS2 as default in Mac vanilla sage * compiling boost against sage python * get sage to use system python or fink python The first seems to be the best of bad alternatives. The third is obviously running against the considered opinion of the sage developers, and the fourth is obviously running counter to a sage axiom. It would suit me a lot if the sage project adopted one of the first two, but there may be no other mac users writing compiled extensions for sage outside of cython. Dunno. I'm not trying to talk you into appearing to offer binary compatibility as a matter of policy. It could even make sense to have a policy of deliberately breaking compatibility on all platforms. D > This is more general: If you want to use Sage with the system's python > you are on your own IMHO. The complexity to debug problems is insane > since you never know how python was compiled and when the user did use > the system python and when Sage's. Switching back and forth will > happen and make it even more murky. I don't mind that people do use > the system python or use custom build options if they know what they > are doing, but people have and will shoot themselves in the foot and I > have little time to help them since I have plenty of bugs to fix in > "vanilla" Sage. It is the old open source mantra: If you break Sage by > doing something stupid you get to keep the pieces :) - and we should > not encourage people to do something stupid. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
