[Bf-committers] Meeting minutes, august 9, 2009

Campbell Barton ideasman42 at gmail.com
Mon Aug 10 04:53:48 CEST 2009


All 64bit py modules, 2.2mb compressed.
These be extracted into ~/.blender/python or release/python and
blender will find and use them on startup.
So you should (for example) be able to access
"release/python/lib/python3.1/io.py"

http://www.graphicall.org/ftp/ideasman42/python31_modules_linux_64bit.tar.bz2

On Sun, Aug 9, 2009 at 7:13 PM, Campbell Barton<ideasman42 at gmail.com> wrote:
> 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
> linux.
>
> 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.
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5/PythonAPI_31#Removing_Modules
>
>
> 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...
> scons BF_PYTHON="/opt/py31"
>
>
> 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
>>
>> http://blenderartists.org/~theeth/temp/python3.1.zip
>>
>> 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.
>>
>> Martin
>>
>>
>>      __________________________________________________________________
>> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
>> http://ca.toolbar.yahoo.com.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
>



-- 
- Campbell


More information about the Bf-committers mailing list