[Bf-committers] solving the issues of switching to python 2.4
on Os X for next release
blender at djc.people.sgalliance.com
Wed Aug 24 00:39:14 CEST 2005
On Tue, 2005-08-23 at 17:32 -0300, Willian Padovani Germano wrote:
> And for Linux (not sure, haven't followed distros
> recently and some are more up to date than others), it's probably about
> time for 2.4, too.
> But it seems this must be decided per platform when possible, situations
> are quite different from one to another.
Debian stable has helped to establish a realistic level of the most
legacy systems we should consider supporting. We probably can safely
assume that most distros are running at this level or more recent
especially by the time we're ready to release in the fall.
It's partially because of this that we've linked against glib 2.2.5
(which is quite dated) for the past few releases. Now that debian has
updated stable to 2.3.2 we may end up wanting to rethink this and move
forward to 2.3.2 for blender. By October/September most linux
installations that would be upgrading to the new version of blender will
likely be using this version or greater. Not only was debian stable
used to create the chroot (and will likely be used for any new ones), it
has also helped define what versions of libraries we can realistically
The point of all this is that the newest debian stable currently
contains python 2.3.5, which means that to support legacy systems
blender probably shouldn't mandate python 2.4 or above on linux.
I think that with linux it makes a lot more sense to link dynamically
with whatever version of python is on the system. Right now the
official builds when run always use python 2.3. I unsure of what work
the python team would have to do to allow blender to use a newer version
if one exists... does this seem feasible? (It would be nice to also be
able to have a fallback option where blender uses an internal version if
a full python installation is missing. Unfortunately some distribution
still don't come with python by default.)
There's also the option of using the existing "static" and "dynamic"
builds for this I suppose... anyways, sorry for intruding on the OSX
conversation but this issue will be a tricky one for all of the
platforms. (Ironically windows will likely be the least troublesome as
python usually isn't found on those systems anyways.)
More information about the Bf-committers