Re: [Bf-committers] CMake Build Changes
On Mon, Mar 7, 2011 at 8:46 PM, Richard Shaw hobbes1...@gmail.com wrote: On Mon, Mar 7, 2011 at 8:50 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: At Sun, 6 Mar 2011 09:12:57 +, Campbell Barton wrote: On Unix/Linux (but not Apple), there is still the case where you can either do a portable install or a system install into /usr/bin/, /usr/share/blender... etc. For this case I've added an option WITH_INSTALL_PORTABLE, Enabled by default, when disabled the files will be installed into the system directories. Why was blenderplayer dropped from the system install? Now I have to install it manually... Yup. I ran into the same issue. It's built but not installed. I would think that WITH_PLAYER should also take care of installing it, no? Richard Hi, removed this by accident, fixed r35402. Sorry for the inconvenience. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
Hi, It's also my fault, I slipped making minutes of meeting 9 days ago, and forgot to include the py 3.2 topic in last meeting's notes. The issue was extensively discussed in irc for 1 or 2 weeks though. The windows/osx platform maintainers checked on it, and when all went smooth for these platforms I assumed it would be fine for Linux too. I know for these cases we should first send a notice to this list and take a week's time before final decisions. :) Which also brings me to the point that for Linux only Ken Hughes is on the maintainer list mentioned. Might be good to add at least 1 or 2 names who should at least be involved with decisions like this? -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 8 Mar, 2011, at 5:55, Campbell Barton wrote: @Martin, no this wasn't discussed at the meeting, once we had other platforms supported Ton was ok for me with the decision. @Diego, yep, was aware I'd get some complaints, but for updates on non-development systems couldn't they use build made elsewhere with py3.2 bundled?. Python do a new releases fairly in-frequently, I recall when we first moved to Py3.1 (dropping 2.x) there were hardly any packages in distros and most Linux devs needed to build, though I expect we have a lot more people building blender now. Seeing as this will happing every 1-2 years? (3.1 was released over 18 months ago), every time this will be a similar situation where Linux devs/builders are comfortable with having easily available packages and suddenly don't. Other then waiting a few months for packages to emerge in mainstream distros or bundling python source with blender - I can't see a way around this. Nevertheless we can make this a meeting topic for next time. On Tue, Mar 8, 2011 at 12:05 AM, Diego B bdi...@gmail.com wrote: Hi, Don't take this bad, but this python thing is staring to be a little annoying... yes download and build/install the new version is just 3 command, but that is fine for one machine that is for development.. when you have to update a couple more of PCs that are begin used to work every day.. not really nice (not mention the servers). Of course you already know about this but anyway, just my two cents. - Diego On Mon, Mar 7, 2011 at 8:35 AM, Campbell Barton ideasma...@gmail.com wrote: Now we have Mac Windows building with python 3.1 we can drop support for all OS's. For Linux this probably means you'll need to build your own since few distributions support py3.2 yet. I've updated the instructions for building python here. http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux/Troubleshooting#Python note, since our wiki update the syntax highlighting has gone a strange (since moving servers) so some text is easier to read when selected. One gotcha with 3,.2 is that python now has a suffix which depends on build-options so you may have libpython32mu.so or libpython32d.so, where before it was simply libpython32.so. From ./configure.in * --with-pydebug (adds a 'd') * --with-pymalloc (adds a 'm') * --with-wide-unicode (adds a 'u') This means getting the path to includes libs isn't so simple anymore, for linux it may be best to search for all possibly combinations of d/m/u to detect the python version, but for now these need to be set manually. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On 03/08/2011 11:39 AM, Ton Roosendaal wrote: Hi, It's also my fault, I slipped making minutes of meeting 9 days ago, and forgot to include the py 3.2 topic in last meeting's notes. The issue was extensively discussed in irc for 1 or 2 weeks though. The windows/osx platform maintainers checked on it, and when all went smooth for these platforms I assumed it would be fine for Linux too. I know for these cases we should first send a notice to this list and take a week's time before final decisions. :) Which also brings me to the point that for Linux only Ken Hughes is on the maintainer list mentioned. Might be good to add at least 1 or 2 names who should at least be involved with decisions like this? -Ton- It would be nice if blender maintainers of major linux distributions could get notification of changes that affect builds as well, myself (openSUSE) and Ken Shaw (Fedora) are now collaborating with blender and openCOLLADA. It's difficult for me to sort through this list and svn logs to find information, I also maintain multimedia and I have a few other lists to follow. Thanks Dave P ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] A big problem with python 3.2
I've now found that blender no longer builds with python 3.1 at all. This creates a problem that the latest blender is in the graphics devel project and python 3.2 is in devel:languages:python:Factory so in order to install blender the user also has to enable the devel:languages:python:Factory repository because that is the only place it is available, the just released 11.4 still has python 3.1 which from what I have read is the same in Ubuntu, Fedora and most probably Mandriva. Please can blender be made to build with python 3.1 again. Thanks Dave P ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New WeightVGroup Modifier
Yet another big functionality improvement release (this should be the last one for a while – I intend to focus on weighted subdivision now…): *Textures can now be used as weight factor sources as well (via a forth mode, Texture). Huh! Took me an hour to figure out that using texture ID implied to implement a foreachIDLink func! *I Added an optional custom curve mapping to affect the weight factor before mixing it with old weight. Note this implied to edit writefile.c/readfile.c, to store/load that curve! -- tracker: http://projects.blender.org/tracker/index.php?func=detailaid=26108 wiki: http://wiki.blender.org/index.php/User:Mont29/WeightVGroup Debian testing amd64 builds: *debug: http://graphicall.org/builds/builds/showbuild.php?action=showid=1731 *optimized: http://www.graphicall.org/builds/builds/showbuild.php?action=showid=1736 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] SVN 35405 compile problem
I checked out a more current svn to get the fix for blenderplayer not installing and hacked bpy_util to not complain about python 3.1 but ran into another issue: /builddir/build/BUILD/blender-2.56.svn35406/source/blender/python/generic/py_capi_utils.c:98:3: error: implicit declaration of function 'PyFrame_GetLineNumber' /builddir/build/BUILD/blender-2.56.svn35406/source/blender/python/generic/py_capi_utils.c:215:3: error: implicit declaration of function 'PyUnicode_EncodeFSDefault' Is this due to using python 3.1 or is this unrelated? Thanks, Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN 35405 compile problem
I had the same problems of missing prototypes for functions as i tried to build with 3.1 with just overwriting (ignoring) the checks. That basically means, that this functions are not available in 3.1 but in 3.2, which then might lead to a broken build, since the native function, that can't be called, is replaced with a dummy. Am 08.03.2011 17:24, schrieb Richard Shaw: I checked out a more current svn to get the fix for blenderplayer not installing and hacked bpy_util to not complain about python 3.1 but ran into another issue: /builddir/build/BUILD/blender-2.56.svn35406/source/blender/python/generic/py_capi_utils.c:98:3: error: implicit declaration of function 'PyFrame_GetLineNumber' /builddir/build/BUILD/blender-2.56.svn35406/source/blender/python/generic/py_capi_utils.c:215:3: error: implicit declaration of function 'PyUnicode_EncodeFSDefault' Is this due to using python 3.1 or is this unrelated? Thanks, Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN 35405 compile problem
On Tue, Mar 8, 2011 at 10:48 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I had the same problems of missing prototypes for functions as i tried to build with 3.1 with just overwriting (ignoring) the checks. That basically means, that this functions are not available in 3.1 but in 3.2, which then might lead to a broken build, since the native function, that can't be called, is replaced with a dummy. Then I guess I'm kinda stuck for Fedora 14 which only ships with 3.1. I'm still learning SVN. Is there a way to determine what is the highest revision that will still build under Python 3.1? I'll just patch that one up the best I can and call it a day until I upgrade to Fedora 15 when it gets released. I guess the other option is to bundle 3.2 but Fedora (and Linux distros in general) frowns on that. Thanks, Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A big problem with python 3.2
Wow, so many people desperate with python 3.2! For my part I had some difficulty with python but nothing that a few edits in the CMakefile couldn't correct. I think being able to build blender is much more trouble than building python 3.2. Just my 2 minority cents to support the dev's decision :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A big problem with python 3.2
2011/3/8 Ρυακιωτάκης Αντώνης kal...@gmail.com: Just my 2 minority cents to support the dev's decision :) Oh, you're not the only one. I've been compiling blender against my own build of python ever since the python-3 requirement was added. -r ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A big problem with python 3.2
2011/3/8 Ρυακιωτάκης Αντώνης kal...@gmail.com: Wow, so many people desperate with python 3.2! For my part I had some difficulty with python but nothing that a few edits in the CMakefile couldn't correct. I think being able to build blender is much more trouble than building python 3.2. Just my 2 minority cents to support the dev's decision :) The issue is not if I can build python 3.2 for my own use but rather how to deal with a distributable package on linux systems that only provide 3.1. Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Linux 64 bit build not making buttons and stuff
I just built svn up; python scons/scons.py BF_DEBUG=1 -j 2; on Kubuntu 10.04 and almost all the button and stuff are gone. The hot keys still work. What's up? Problems seem to start here. How do I fix it? Just wait? Compiling == 'blf_py_api.c' source/blender/python/generic/py_capi_utils.c: In function ‘PyC_FileAndNum’: source/blender/python/generic/py_capi_utils.c:98: error: implicit declaration of function ‘PyFrame_GetLineNumber’ source/blender/python/generic/py_capi_utils.c: In function ‘PyC_UnicodeAsByte’: source/blender/python/generic/py_capi_utils.c:215: error: implicit declaration of function ‘PyUnicode_EncodeFSDefault’ source/blender/python/generic/py_capi_utils.c:215: warning: assignment makes pointer from integer without a cast source/blender/python/generic/py_capi_utils.c:215: warning: assignment makes pointer from integer without a cast scons: *** [/home/douglas4/Blender/build/linux2/source/blender/python/generic/py_capi_utils.o] Error 1 scons: building terminated because of errors. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Linux 64 bit build not making buttons and stuff
Hi, We moved to python 3.2, check the other long thread here :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 8 Mar, 2011, at 19:54, Knapp wrote: I just built svn up; python scons/scons.py BF_DEBUG=1 -j 2; on Kubuntu 10.04 and almost all the button and stuff are gone. The hot keys still work. What's up? Problems seem to start here. How do I fix it? Just wait? Compiling == 'blf_py_api.c' source/blender/python/generic/py_capi_utils.c: In function ‘PyC_FileAndNum’: source/blender/python/generic/py_capi_utils.c:98: error: implicit declaration of function ‘PyFrame_GetLineNumber’ source/blender/python/generic/py_capi_utils.c: In function ‘PyC_UnicodeAsByte’: source/blender/python/generic/py_capi_utils.c:215: error: implicit declaration of function ‘PyUnicode_EncodeFSDefault’ source/blender/python/generic/py_capi_utils.c:215: warning: assignment makes pointer from integer without a cast source/blender/python/generic/py_capi_utils.c:215: warning: assignment makes pointer from integer without a cast scons: *** [/home/douglas4/Blender/build/linux2/source/blender/python/generic/ py_capi_utils.o] Error 1 scons: building terminated because of errors. -- Douglas E Knapp Creative Commons Film Group, Helping people make open source movies with open source software! http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php Massage in Gelsenkirchen-Buer: http://douglas.bespin.org/tcm/ztab1.htm Please link to me and trade links with me! Open Source Sci-Fi mmoRPG Game project. http://sf-journey-creations.wikispot.org/Front_Page http://code.google.com/p/perspectiveproject/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] A big problem with python 3.2
Source distros are a different topic... but for that a dependency with Python 3.2 sources can be added? I checked last night and Python 3.2 is currently masked in Gentoo. Tonight, I will unmask it and see if there are compilation issues. Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Bevel weights status?
Is there any plan to or when to include bevel weights? Currently anything seams to be present, but no operator/shortcut/tool to edit them. All i could find is a script for 2.43 which did set them. But currently it is broken (API Changes). Any hint what i can expect in this regard? Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender native compile for headless servers???
On Tue, Mar 8, 2011 at 6:58 PM, pete larabell xgl.asyl...@gmail.com wrote: Hi all, Is it entirely too complex and/or impossible to have (at some point in the future) a compile flag (ex. WITH_HEADLESS) that would allow for a compile that would always run in background render mode? I guess blender is run on enough render servers where there is no terminal at bigger shops. Would making a always-headless compile version reduce required dependencies at all? Cheers, Peter Hi, we could reduce binary size and deps with a headless build. objdump blender.bin -x | grep NEEDED libGL.so.1 libGLU.so.1 libjpeg.so.8 libpng14.so.14 libz.so.1 libutil.so.1 libpthread.so.0 libstdc++.so.6 libX11.so.6 libXi.so.6 libdl.so.2 libpython3.2d.so.1.0 libfreetype.so.6 libHalf.so.6 libIlmImf.so.6 libIex.so.6 libImath.so.6 libc.so.6 libm.so.6 libgcc_s.so.1 --- from this list we could remove GHOST dependency and libGL.so.1 libGLU.so.1 libX11.so.6 libXi.so.6 Probably the easiest way to maintain this would be to use stubs for ghost and opengl so we dont litter our codebase with ifdef's. Brecht did this once for some renderfarm testcase, so he may have some suggestions. - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN 35405 compile problem
On Tue, Mar 8, 2011 at 5:23 PM, Richard Shaw hobbes1...@gmail.com wrote: On Tue, Mar 8, 2011 at 10:48 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I had the same problems of missing prototypes for functions as i tried to build with 3.1 with just overwriting (ignoring) the checks. That basically means, that this functions are not available in 3.1 but in 3.2, which then might lead to a broken build, since the native function, that can't be called, is replaced with a dummy. Then I guess I'm kinda stuck for Fedora 14 which only ships with 3.1. I'm still learning SVN. Is there a way to determine what is the highest revision that will still build under Python 3.1? I'll just patch that one up the best I can and call it a day until I upgrade to Fedora 15 when it gets released. I guess the other option is to bundle 3.2 but Fedora (and Linux distros in general) frowns on that. Thanks, Richard To find out the revision this changed... svn blame /data/src/blender/blender/source/blender/python/intern/bpy_util.h 35386 campbellbarton #if PY_VERSION_HEX 0x0302 Then make a diff... svn diff -c35386 py31_compat.diff Reverse apply the diff... patch -p0 --reverse py31.diff - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [35407] trunk/blender: Bugfix Feature fix: Only Shadow Material options
Am 08.03.2011 17:08, schrieb Ton Roosendaal: Revision: 35407 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=35407 Author: ton Date: 2011-03-08 16:08:43 + (Tue, 08 Mar 2011) Log Message: --- Bugfix Feature fix: Only Shadow Material options Really great! I did run into this problem quite often in the last weeks. BTW: Will old files render different now? Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Particle surfacing question
Hi all :) I have once again teamed with Stephen to finish the implementation of the particle polygonizer,we have fused his modifier approach with my slighly faster polygonizer ... but since I have lost my Realflow demo version I can't have speed reference comparison. We don't use (and I would prefer to avoid) hybrid box boundary polygonizers, I stick to the domain free polygonizer (that certainly have performance penalties at the cost of flexibility) but I would like to know what are the performance expectations. Currently is no threaded, and though some memory allocations can be improved I don't foresee any major speed gain with the current desing and I consider it slow ... it seems to decrease in some factor around O(n2) because for 1000 particles it slows down a lot ... I would need to research around a bit more and some help would be very wellcome, please point me domain free polygonizers out there and their speed. Cheers Farsthary ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Linux 64 bit build not making buttons and stuff
On Tue, Mar 8, 2011 at 7:55 PM, Knapp magick.c...@gmail.com wrote: On Tue, Mar 8, 2011 at 8:16 PM, Ton Roosendaal t...@blender.org wrote: Hi, We moved to python 3.2, check the other long thread here :) -Ton- I glanced at it, so at least I know what you are talking about. I would highly recommend making a web page saying how to make it all work with Ubuntu and other linuxes. I suspect it will save you a lot of trouble. I will now go back to the archives and look for that one email about Ubuntu. Thanks. -- Douglas E Knapp Would be good if people who manage to get packages for py3.2 could include the commands here. http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux/Troubleshooting#Python Since this page is linked to from the header of linux build pages, eg: http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux/Ubuntu/CMake ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] CMake Build Changes
Well, my x64 Windows build (Cmake+MSVC) compiles but it's not installed correctly. blender.exe, makesdna.exe and makesrna.exe (with some vc files) everything else is missing. On 8 March 2011 10:02, Campbell Barton ideasma...@gmail.com wrote: On Mon, Mar 7, 2011 at 8:46 PM, Richard Shaw hobbes1...@gmail.com wrote: On Mon, Mar 7, 2011 at 8:50 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: At Sun, 6 Mar 2011 09:12:57 +, Campbell Barton wrote: On Unix/Linux (but not Apple), there is still the case where you can either do a portable install or a system install into /usr/bin/, /usr/share/blender... etc. For this case I've added an option WITH_INSTALL_PORTABLE, Enabled by default, when disabled the files will be installed into the system directories. Why was blenderplayer dropped from the system install? Now I have to install it manually... Yup. I ran into the same issue. It's built but not installed. I would think that WITH_PLAYER should also take care of installing it, no? Richard Hi, removed this by accident, fixed r35402. Sorry for the inconvenience. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN 35405 compile problem
On Tue, Mar 8, 2011 at 3:25 PM, Campbell Barton ideasma...@gmail.com wrote: To find out the revision this changed... svn blame /data/src/blender/blender/source/blender/python/intern/bpy_util.h 35386 campbellbarton #if PY_VERSION_HEX 0x0302 Then make a diff... svn diff -c35386 py31_compat.diff Reverse apply the diff... patch -p0 --reverse py31.diff If all that does is change bpy_util.h then it doesn't really help you. I did it manually by changing 0x0302 to 0x0301, but there are now some functions that are used that are only available in 3.2. I ended up checking out the prior release, 35385, and then created my own patch from the current release of CMakeLists.txt for the blenderplayer install problem and it compiled without error. I haven't tested it yet though. I'll have to wait till I get home from work for that. Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] CMake Build Changes
In MSVC the install target needs to be checked though you might not want to always be removing python + scripts an re-copying unzipping for every build, for more info see: http://www.mail-archive.com/cmake@cmake.org/msg17035.html On Tue, Mar 8, 2011 at 10:13 PM, Damir Prebeg blend.fact...@gmail.com wrote: Well, my x64 Windows build (Cmake+MSVC) compiles but it's not installed correctly. blender.exe, makesdna.exe and makesrna.exe (with some vc files) everything else is missing. On 8 March 2011 10:02, Campbell Barton ideasma...@gmail.com wrote: On Mon, Mar 7, 2011 at 8:46 PM, Richard Shaw hobbes1...@gmail.com wrote: On Mon, Mar 7, 2011 at 8:50 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: At Sun, 6 Mar 2011 09:12:57 +, Campbell Barton wrote: On Unix/Linux (but not Apple), there is still the case where you can either do a portable install or a system install into /usr/bin/, /usr/share/blender... etc. For this case I've added an option WITH_INSTALL_PORTABLE, Enabled by default, when disabled the files will be installed into the system directories. Why was blenderplayer dropped from the system install? Now I have to install it manually... Yup. I ran into the same issue. It's built but not installed. I would think that WITH_PLAYER should also take care of installing it, no? Richard Hi, removed this by accident, fixed r35402. Sorry for the inconvenience. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] release/plugins/bmake?
Is this file needed for install? It gets installed on linux using make install but with the wrong permissions for an executable script. Looking through the file it seems to be something needed for building... Richard ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
--- On Mon, 3/7/11, Campbell Barton ideasma...@gmail.com wrote: Python do a new releases fairly in-frequently, I recall when we first moved to Py3.1 (dropping 2.x) there were hardly any packages in distros and most Linux devs needed to build, though I expect we have a lot more people building blender now. Python has minor releases every six months or so, sometimes less. Seeing as this will happing every 1-2 years? (3.1 was released over 18 months ago), every time this will be a similar situation where Linux devs/builders are comfortable with having easily available packages and suddenly don't. Unless the benefits outweighs the hindrances, there's nothing lost by waiting until the next minor release. IIRC, there's no syntax changes in 3.2 and the list of bug fixes isn't didn't seem to contain anything urgent. Scripts written for 3.1 will be compatible with 3.2 so there's no good reasons to switch before a Blender release, unless there's a bugfix we really need (is the windows path issue that important?). Other then waiting a few months for packages to emerge in mainstream distros or bundling python source with blender - I can't see a way around this. It's been out two weeks and, if I'm reading this right, it was discussed in meeting two weeks ago. There's a giant gap between being cautious, waiting for distros to pick it up and what happened. Nevertheless we can make this a meeting topic for next time. It's a bit too late now. For important changes like this, it would be nice if the author could at least make sure it's mentioned in the meeting notes or drop an outline of the changes on the ml. I don't think it's too much to ask (again). Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
--- On Tue, 3/8/11, Ton Roosendaal t...@blender.org wrote: Which also brings me to the point that for Linux only Ken Hughes is on the maintainer list mentioned. Might be good to add at least 1 or 2 names who should at least be involved with decisions like this? I can certainly help with that (actually, I thought I might have been on that list at some point, maybe I just don't recall right though). Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Tue, Mar 8, 2011 at 11:00 PM, Martin Poirier the...@yahoo.com wrote: --- On Mon, 3/7/11, Campbell Barton ideasma...@gmail.com wrote: Python do a new releases fairly in-frequently, I recall when we first moved to Py3.1 (dropping 2.x) there were hardly any packages in distros and most Linux devs needed to build, though I expect we have a lot more people building blender now. Python has minor releases every six months or so, sometimes less. True but the versions which break the ABI are major releases. Seeing as this will happing every 1-2 years? (3.1 was released over 18 months ago), every time this will be a similar situation where Linux devs/builders are comfortable with having easily available packages and suddenly don't. Unless the benefits outweighs the hindrances, there's nothing lost by waiting until the next minor release. Agree this could be ok. IIRC, there's no syntax changes in 3.2 and the list of bug fixes isn't didn't seem to contain anything urgent. Scripts written for 3.1 will be compatible with 3.2 so there's no good reasons to switch before a Blender release, unless there's a bugfix we really need (is the windows path issue that important?). No blocking bugs but ~3 reported bugs which directly relate to problems with python, so these are kinds of corner cases but you can also imagine its annoying if blender scripts cant read your home dir. I did manage to workaround these (for the mostpart), but PyUnicode_DecodeFSDefault has no PyUnicode_EncodeFSDefault counterpart in py3.1. Other then waiting a few months for packages to emerge in mainstream distros or bundling python source with blender - I can't see a way around this. It's been out two weeks and, if I'm reading this right, it was discussed in meeting two weeks ago. There's a giant gap between being cautious, waiting for distros to pick it up and what happened. Yep, this is very arbitrary when we upgrade, I'd still like to do this within say a month of release (for Py3.3, not talking about minor releases here) Nevertheless we can make this a meeting topic for next time. It's a bit too late now. For important changes like this, it would be nice if the author could at least make sure it's mentioned in the meeting notes or drop an outline of the changes on the ml. I don't think it's too much to ask (again). I'm writing up some notes on policy for upgrade, will reply with this next. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Tue, Mar 8, 2011 at 11:25 PM, Matt Ebb m...@mke3.net wrote: On Wed, Mar 9, 2011 at 10:00 AM, Martin Poirier the...@yahoo.com wrote: Unless the benefits outweighs the hindrances, there's nothing lost by waiting until the next minor release. This sounds sensible to me. Considering the widespread inconvenience caused by these sorts of things, it would seem that unless there's something dire that needs to be fixed by an update immediately, then it would be much better to wait a while so people can build from their linux distros easily, so that people using external modules don't get stuck, and so that any new bugs brought in by a new Python version can be avoided. Just because a new Python version is released doesn't mean that blender needs to start using it immediately - many 3d apps are still using Python ~2.5. Like Martin said, it's a case of benefits vs hindrances, and as time goes by and more people are getting on board with Python in Blender 2.5, the hindrances side of the equation is getting heavier and heavier, which means these changes need to be approached with a greater level of sensitivity and care. I feel this also applies to API changes now too. I'm not against change in itself, but I do feel that the current degree of external costs in the cost/benefit relationship isn't being given serious enough treatment. cheers Matt As said before in the last mail, its fairly arbitrary when we upgrade. But I'd really not want to have to worry about maintaining 2 versions of python for more then a months, two months at most. We can upgrade python without causing too much inconvenience just be ensuring we document how to install the latest python. I thought that documenting how to build python would be enough, but it seems us bearded linux geeks who like to compile blender from source are for some reason not ok about building python. ok, we can include instructions for getting python testing packages too. Heres my proposed policy for major upgrades... http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Py3.1_Migration#Python_Upgrade_Policy --- copying main points from the wiki. * Linux platform maintainers first agree to drop support. * Include a note in meeting minutes beforehand that the python version will be no longer supported. * Ensure build instructions are up to data for Ubuntu/Fedora to install packages (most likely from testing repo's). regarding API stability, rather discuss that separately. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Tue, Mar 8, 2011 at 6:13 PM, Campbell Barton ideasma...@gmail.com wrote: We can upgrade python without causing too much inconvenience just be ensuring we document how to install the latest python. I thought that documenting how to build python would be enough, but it seems us bearded linux geeks who like to compile blender from source are for some reason not ok about building python. ok, we can include instructions for getting python testing packages too. I'm only speaking for myself (though I *think* Dave P. would agree with me)... The problem is not that I'm personally against compiling python for my own use. The problem is that I'm trying to create and maintain a distributable package for a specific linux distribution that does not ***and will not have*** python 3.2 available to normal users who don't compile things for themselves. I am not saying that there were not good reasons for going to 3.2, I just wanted to clarify, at least for myself, why it's a problem. Respectfully, Richard M. Shaw ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Wed, Mar 9, 2011 at 1:45 AM, Richard Shaw hobbes1...@gmail.com wrote: On Tue, Mar 8, 2011 at 6:13 PM, Campbell Barton ideasma...@gmail.com wrote: We can upgrade python without causing too much inconvenience just be ensuring we document how to install the latest python. I thought that documenting how to build python would be enough, but it seems us bearded linux geeks who like to compile blender from source are for some reason not ok about building python. ok, we can include instructions for getting python testing packages too. I'm only speaking for myself (though I *think* Dave P. would agree with me)... The problem is not that I'm personally against compiling python for my own use. The problem is that I'm trying to create and maintain a distributable package for a specific linux distribution that does not ***and will not have*** python 3.2 available to normal users who don't compile things for themselves. I am not saying that there were not good reasons for going to 3.2, I just wanted to clarify, at least for myself, why it's a problem. Respectfully, Richard M. Shaw blender.org only supports official builds which are generally self contained builds with static libs. package builds use different flags, have patches applied and in the past at least we didn't support these, not sure if this still applies. eg: Gentoo package used to enable the YESIAMSTUPID define for unsupported 64bit linux :) Package maintainers could build with python 3.2, enable WITH_PYTHON_INSTALL voila the package will contain python 3.2 too. Of-course this is not the gnu/debian way which prefers shared libs where-ever possible. Debian even discussed dropping blender because of this: http://lists.debian.org/debian-devel/2009/08/msg00088.html Not an excuse to make it hard for package maintainers, just to put this in context that blender has been doing things `not the linux way` for a while now. Only supporting a single version of python IMHO is important to reduce overhead with a small developer team, for a while I was making sure python 2.6, 3.0, 3.1 all worked but it just took time. Granted py3.1-3.2 is nowhere near the same amount of API changes and I'm ok to support both for some transitional period but not continuously - we did this with blender 2.4x - py2.3/4/5, where we got irritating breakages because of version incompatibilities, I had to have all python versions installed and remember what features were available in 2.3x so as not to use. My impression is that if we only support 1 python version there will always be Linux distros that are behind or ahead whatever python we choose wont be supported. Ofcourse we can hold back on upgrading at all as Matt suggests but then its frustrating not to be able to use an updated python with fixes on other OS's just because of Linux (which make up some small % of blenders userbase, Ton has numbers) For some background info this is the original thread about bundling python. http://lists.blender.org/pipermail/bf-committers/2008-December/022277.html Since blender is not stable yet, I think its reasonable to target Fedora 15 Ubuntu (Natty) which will have py3.2. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
--- On Tue, 3/8/11, Campbell Barton ideasma...@gmail.com wrote: As said before in the last mail, its fairly arbitrary when we upgrade. But I'd really not want to have to worry about maintaining 2 versions of python for more then a months, two months at most. You're saying that like we HAD to support Py 3.2. We didn't. We could just have kept on only supporting 3.1 for months. Heres my proposed policy for major upgrades... http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Py3.1_Migration#Python_Upgrade_Policy --- copying main points from the wiki. * Linux platform maintainers first agree to drop support. All platform maintainers should be involved. * Include a note in meeting minutes beforehand that the python version will be no longer supported. Should be separate from minutes, it's an important subject that warrants its own thread. * Ensure build instructions are up to data for Ubuntu/Fedora to install packages (most likely from testing repo's). Sounds good, but there's nothing in there as to HOW to decide when to upgrade. It's a list of things to do after the decision has been taken (which, ok, is nice, but is not the main issue here). The fact that someone can flip a switch and have everything work with a newer version is not a solid reason to upgrade such a dependency. Martin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender native compile for headless servers???
Hi, On Tue, Mar 8, 2011 at 9:58 PM, Campbell Barton ideasma...@gmail.com wrote: Probably the easiest way to maintain this would be to use stubs for ghost and opengl so we dont litter our codebase with ifdef's. Brecht did this once for some renderfarm testcase, so he may have some suggestions. What I did was compile without editors/, but then you still have the problem that OpenGL is used in other places, and perhaps you want the use the operators that are in editors/. So adding stubs for OpenGL and Ghost is probably the least intrusive solution if someone wants to implement this. Brecht. Hi Brecht, I am planning to implement this so a quick question. Are their any major huddles you came across that are worth mentioning other than what you have stated here? - Steve -- Software Developer www.sobbayi.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On Wed, Mar 9, 2011 at 4:15 AM, Martin Poirier the...@yahoo.com wrote: --- On Tue, 3/8/11, Campbell Barton ideasma...@gmail.com wrote: As said before in the last mail, its fairly arbitrary when we upgrade. But I'd really not want to have to worry about maintaining 2 versions of python for more then a months, two months at most. You're saying that like we HAD to support Py 3.2. We didn't. We could just have kept on only supporting 3.1 for months. Heres my proposed policy for major upgrades... http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Py3.1_Migration#Python_Upgrade_Policy --- copying main points from the wiki. * Linux platform maintainers first agree to drop support. All platform maintainers should be involved. * Include a note in meeting minutes beforehand that the python version will be no longer supported. Should be separate from minutes, it's an important subject that warrants its own thread. * Ensure build instructions are up to data for Ubuntu/Fedora to install packages (most likely from testing repo's). Sounds good, but there's nothing in there as to HOW to decide when to upgrade. It's a list of things to do after the decision has been taken (which, ok, is nice, but is not the main issue here). The fact that someone can flip a switch and have everything work with a newer version is not a solid reason to upgrade such a dependency. Martin Made suggested changes: http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Py3.1_Migration#Python_Upgrade_Policy Regarding not-upgrading. Ye don't _have_ to upgrade at all, for core language stuff its pretty stable and not changing much between releases so can see your point. But since we distribute all the libraries too, these get a lot of improvements fixes each release, I'd argue that its worth upgrading and not waiting say - 6months for this reason alone. see: http://docs.python.org/py3k/whatsnew/3.2.html Unless some unusual problem with the new python comes up, I'd like to upgrade once they do a stable release blender platform maintainers are ok to go ahead. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Moving to Python 3.2.x
On 03/09/2011 05:24 AM, Campbell Barton wrote: Only supporting a single version of python IMHO is important to reduce overhead with a small developer team, I'm still in the dark as to why external system python which is maintained by the distro python maintainer has to be 3.2 for blender to build against. This is no maintenance on your side and the distribution blender maintainer takes care of the bugs (supposed to anyway) and if it is an upstream blender bug passes correct information and in some cases offers a patch to solve the bug. There's nothing wrong with blender having a particular version of python bundled with it but why can't it build with the distributions python 3.1. This is for the silent majority of users who want software that works and don't have a wish to build it themselves. Give us a clue about where the changes are that prevent the use of 3.1 and we will patch it ourselves in which case it becomes our maintenance problem but that's why we're maintainers. Thanks Dave P ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
