[Bf-committers] Meeting minutes, august 9, 2009
ideasman42 at gmail.com
Mon Aug 10 04:13:42 CEST 2009
The situation with linux is not so clear cut, it seems nobody agree
on this so I assumed we were not going to add a compiled py libs for
linux, but I have no problems with doing this.
Apparently there is some problem with having a linux ../lib at all
because of glibc version incompatibilities. Im not sure about this but
it was mentioned as a reason not to include ffmpeg in ../lib for
Nevertheless, I can make the 64bit linux python31.zip. We can see how
it goes if people get glibc errors or not.
here are some notes for what modules to remove.
For devs who want to build your own python (if your distro has no
py3.1 package yet) this is very easy to do without installing into
your system and confusing the package manager.
# Extract python 3.1 source. Note, /opt/py31 is just an example.
./configure --prefix="/opt/py31"; make
sudo make install
# Now in blenders dir do...
On Sun, Aug 9, 2009 at 6:58 PM, Martin Poirier<theeth at yahoo.com> wrote:
> --- On Sun, 8/9/09, Ton Roosendaal <ton at blender.org> wrote:
>> - Python 3.1 move: all signs are on green now; but for
>> using Scons
>> building, you'll still have to keep Py 2.6 around until
>> Scons also
>> migrates. This isn't so much a problem, since we'll include
>> the library
>> and includes in our svn, so you don't have to install
>> python 3.1.
>> Campbell will remove the ugly compatibility #ifdefs
>> tomorrow, be
>> warned! He'll be around in IRC to advise or help.
> Here's a linux zip for py 3.1
> It was built on linux 32 with glibc2.8 (the last one probably doesn't matter much).
> As far as I know, the only architecture specific part (which would need a linux 64 counterpart) is /lib-dynload while the only platform specific stuff is in /plat-linux2
> All the rest should be both platform and architecture agnostic.
> Now, what we would need to do is have that zip in .blender and unzip it on startup (if not done already). The unzip is needed because python can only (IIRC) load pure py modules from zip and not dynamic binary libs. Unzipping the pure py modules is good anyway because it gives a space for pyc files and speed up module loading. We would also need to distribute the python .so lib as well as a special startup script to find it properly.
> Note that we would still need a full python 3.1 install on build machines. Removing that dependency would need adding include files and prebuilt libs in /libs/linux* (I would recommend that does be optional and that the build engines uses system libs by default).
> In a perfect world, these would have been solved before removing 2.6 support, but I digress.
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers