[Bf-committers] Branch merging and buildbot - propose to change build cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, With the recent amount of branch merging and the amount of post-fixing it generated, some of it due to different platforms in use by developers I'd propose to change buildbot to build more often, even on per-commit basis. This would allow developers to see pretty easy how their work behaves with all necessary logs available. We know that many developers turn of lots of features while working on their own beautiful little garden, sometimes resulting in clipping of nice flowers from other developers (blenderplayer, cross-platform code, etc.). Buildbot is running very well currently and gives useful output, but for developers the nightly cycle can be too long to wait for. Changing to build-on-change will make buildbot much more useful. Buildbot output should become mandatory part of toolset of developers, with the proposed change it will make actually sense too. /Nathan ps. right now linux builds both failed due to navmesh code ( http://builder.blender.org/grid ) - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObaKIAAoJEKtfN7KsE0TtnUcIAKdyAFUyEUWKg1BjcjsrKNTb pGwvSEJXB/31Afu2LddMosMVVhQO5pEyUpKEwdol2EVqdNeVl88Jto7m/sP9OJUi ILe8UXrabSyHzOWtiJR0kCsAt83XVsJ+ztL1ijCw27K0Q2kJvAjKLM3GF1/7vrFl taWZg3SWTEPvQXBJhkJE2thT+EzJ9pwlk0ADEaZCwFKep18bA+TZroMvugmT166f EMGH046UNhZ4VroL54WUETLNYboCjSspAtZXtPo2NLadLWgMUdDLgAclw5YKUXnz TeJvfI/d822OUAnZeaBwp/zgsZTZRVLX62jU5Gk6v/s9/lZSrHP4BWJxYFoUydQ= =f4VP -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Branch merging and buildbot - propose to change build cycle
Hi, Not sure having this behavior always is nice. It's not really needed when you aren't merging and when you're doing merge, you can trigger re-build easily. And there's no need to rebuild Windows build when you're solving issues with Linux platform. About linux slaves.. Looks like there's no version of qsort with one additional argument to callback (like qsort_r and qsort_r) in older versions of libc. We've got two occurrences of this call - one in our navmesh_conversion.cpp and another in recast library. This function isn't used in current raycast svn and i think it can be easily replaced with own implementation of qsort for navmesh_conversion.cpp. Btw, why we've got C++ source in blenkernel? I heard it's because of recats is writtein in C++. But in this case we're writting C-API and storing it in extern/library/library_C-API.c. Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, With the recent amount of branch merging and the amount of post-fixing it generated, some of it due to different platforms in use by developers I'd propose to change buildbot to build more often, even on per-commit basis. This would allow developers to see pretty easy how their work behaves with all necessary logs available. We know that many developers turn of lots of features while working on their own beautiful little garden, sometimes resulting in clipping of nice flowers from other developers (blenderplayer, cross-platform code, etc.). Buildbot is running very well currently and gives useful output, but for developers the nightly cycle can be too long to wait for. Changing to build-on-change will make buildbot much more useful. Buildbot output should become mandatory part of toolset of developers, with the proposed change it will make actually sense too. /Nathan ps. right now linux builds both failed due to navmesh code ( http://builder.blender.org/grid ) - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObaKIAAoJEKtfN7KsE0TtnUcIAKdyAFUyEUWKg1BjcjsrKNTb pGwvSEJXB/31Afu2LddMosMVVhQO5pEyUpKEwdol2EVqdNeVl88Jto7m/sP9OJUi ILe8UXrabSyHzOWtiJR0kCsAt83XVsJ+ztL1ijCw27K0Q2kJvAjKLM3GF1/7vrFl taWZg3SWTEPvQXBJhkJE2thT+EzJ9pwlk0ADEaZCwFKep18bA+TZroMvugmT166f EMGH046UNhZ4VroL54WUETLNYboCjSspAtZXtPo2NLadLWgMUdDLgAclw5YKUXnz TeJvfI/d822OUAnZeaBwp/zgsZTZRVLX62jU5Gk6v/s9/lZSrHP4BWJxYFoUydQ= =f4VP -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Branch merging and buildbot - propose to change build cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.9.2011 9:27, Sergey I. Sharybin wrote: Hi, Not sure having this behavior always is nice. It's not really needed when you aren't merging and when you're doing merge, you can trigger re-build easily. And there's no need to rebuild Windows build when you're solving issues with Linux platform. Indeed, but it happens regularly that builds break on different platforms, and even more so because developers *don't build with all features enabled* (while in theory they should always verify the entire build before doing any commits). Sure, triggering manually is a way, but it is even better to not have to do that. Developers are lazy beings (hence they are developers). With the amount of developers that we have commiting I think its especially nice if our buildslaves would just build the moment they don't have anything to do and are notified of changes. /Nathan - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObbw4AAoJEKtfN7KsE0TtBkwH+wTA5skYb86CIeEN3VqEW8xs 8Jzorq4Ip4ySfrsbv8v1HDKcHNJvQzO0SmWHYD7KPunwqsFFquqXc3iIEFoG+43B xvDsA/paFxE6iz6AzpzqIvP4oMHL1YJXnokiBdxrGf+Go6RFehKKkTFY4UfHLH+7 OpvPYQk/zdEMCjG5Yz8lv7WFzjPwzaVPLFCkXH5HFFfRgnY2OjEoO0wlJXsUTISu c4aqqXWSOHQmFrHdCdKvVVU3v16Gqpryi2S5J2ghU1onzimTvApGiIcTWVru/rNU bUrMgY8Cacs1Jl4OkOEzTybZnnxJWrYM7SMWHjWAFbwsZBGwwft8rQaj1NsJ43I= =YPMf -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender developers IRC meeting notes, 11 september 2011
re: texface I read the complete log (thanks Nathan L.) and got a better feeling of how this was brought up in the meeting. Ton mentions Sep.22. Is this for final merges or for final fixes after merges? Anyhoo I started a final round of tests and updated the patch. Sintel files work fine (no popups = good) so it will likely not annoy non-bge users. And I'm finishing getting YF to test. There is one (last) bug left though, for which I could use some help. When the object has no material is not rendering the alpha. I guess I need to fiddle further with drawobject.c sample: http://dl.dropbox.com/u/3292898/texface/bugs/alpha1_3dview.blend -- Dalai 2011/9/11 Dalai Felinto dfeli...@gmail.com - What's status of TexFace properties migration? Dalai Felinto knows! I was waiting for the dust to settle on decast/retour :) Originally I was even waiting for after cucumber. But Daniel said they are still small bugs with lighting there and I still want to other code maintainers to help reviewing some parts of it. That said, I'm doing a re-sync with trunk here, will do a last round of tests and commit. This will include subversion bumping (from 2 to 3), change in the preview.blend and a popup when converting of materials fail (not a big deal, but it will alert of of that for every file you have before you save them with 2.59.3). I'm hoping go smooth. After committing I will prepare a code.blender.orgpost to orient artists. Cheers, Dalai 2011/9/11 Ton Roosendaal t...@blender.org Hi all, Here's a summary of today's topics: 1) Next release - BCon schedule and targets: http://wiki.blender.org/index.php/Dev:Doc/Projects - What's status of TexFace properties migration? Dalai Felinto knows! - UI translation branch; in progress, Sergey Sharybin thinks it can make it this week. Some features are a regression compared to 2.4 though (needs restart, no 'only tooltips'). The specifications need to be confirmed. Sergey checks with Brecht van Lommel if there's a solution to use RNA for translation directly. - Weight Paint GSoC branch: the functionality review was very positive. Campbell Barton offers to check the code, Sergey helps. Thomas can help with UI script if needed. Agreed is this only gets in trunk if non-intrusive and compatible. Otherwise it better moves to next release. - Reminder for people working on UI: http://www.blender.org/documentation/blender_python_api_2_59_2/info_best_practice.html#user-interface-layout - Branch merger of recast detour went unlucky... after merger developer had to leave, leaving trunk unusable. Meeting agrees confirms that anyone who does bigger commits should stay around for as long is needed to help fixing the immediate issues. - Ocean sim: Matt Ebb committed fixes, code needs to be uploaded for final review. Should be in our tracker by now? Review can now progress, target set for 2.61. Need to find reviewers too! 2) other projects - Nurbs Branch: Emmanuel Stone is back to help with it too. Needs to set it going, Sergey is available for it too! - Bug Tracker work: everyone with a projects.blender.org account can help reviewing bugs. It's a lot of work to do the initial triaging. Several volunteers popped up to review new incoming reports to help making it clear cases for a coder to tackle. - BMesh: progress goes well, Campbell hopes to find more time for it. Ender added to team as bf-project member for BMesh commit access. - Cycles: Brecht focuses on UI/integration issues, also with 2.61 getting closer. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ 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] Branch merging and buildbot - propose to change build cycle
Hi, Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Indeed, but it happens regularly that builds break on different platforms, and even more so because developers *don't build with all features enabled* (while in theory they should always verify the entire build before doing any commits). Sure, triggering manually is a way, but it is even better to not have to do that. Developers are lazy beings (hence they are developers). With the amount of developers that we have commiting I think its especially nice if our buildslaves would just build the moment they don't have anything to do and are notified of changes. Well, just triggering isn't enough. It wouldn't make developers check buildbot logs, IMO. It should also punish developers who breaks something. Or at least notify them. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Branch merging and buildbot - propose to change build cycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.9.2011 12:01, Sergey I. Sharybin wrote: Hi, Nathan Letwory wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Indeed, but it happens regularly that builds break on different platforms, and even more so because developers *don't build with all features enabled* (while in theory they should always verify the entire build before doing any commits). Sure, triggering manually is a way, but it is even better to not have to do that. Developers are lazy beings (hence they are developers). With the amount of developers that we have commiting I think its especially nice if our buildslaves would just build the moment they don't have anything to do and are notified of changes. Well, just triggering isn't enough. It wouldn't make developers check buildbot logs, IMO. It should also punish developers who breaks something. Or at least notify them. Agreed. /Nathan - -- Nathan Letwory Letwory Interactive | Studio Lumikuu http://www.letworyinteractive.com | http://www.lumikuu.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJObeXKAAoJEKtfN7KsE0TtjwwH/3FSUwYBqxciBlBZKWkWO8cY JD88NsNH8MWCrNGoFkBEYg5CMjcRaTTctHICUVavjNA8xpfocbwtpiI7yPg57THx yj0mTBtyfgifR/ANGAUdAHM0rmigtO4i4KrLPdIu/YTpBurEpO3qXXi8r/PJanDl 9xDotbo6RmP/TUTwZDOKL/Fvmm9QccX2kXzInHZwNmtIJ2n+y2AURIJfQ/t/mj7f MK7WMeXlAngY3XRM5qT43NRmC7JYPsu8SobWWIHrAQ7dYuPcbCOBo9Xj6HUq8E3S 0C7bVAyqi7D8qs8oOuMKRjFGk5afxOaTjFbgh2xvLAzjdbdmP2Y2SEvqwcaP95c= =WxLy -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles MinGW compilation
Hi everyone, I ve been working on getting cycles compile with MinGW lately. I've managed to get the compilation part right but I still run into linking issues: boost and openimageio. I have managed to get boost to compile under MinGW and got rid of the boost link errors but openimageio still has some problems. There are a few problems internal to MinGW: the lack of strtok_r function and localtime_r functions. So far I have made some progress substituting those with the strtok and localtime variants but since the former are supposed to be thread safe and the latter are not this does not look good. In addition, strtok_r is needed by ptex too so it will cause trouble when merging ptex too. It actually made me switch off ptex in onion GSOC project during the summer when on MinGW. So I thought I would ask for opinions on the matter. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles MinGW compilation
Hi brecht, excellent! By the way, what configuration enable flags do you use with cmake when compiling? I use the following: cd C:\Users\Psy-Fi\workspace\oiio cmake C:\blender_svn\oiio\src\ -G Eclipse CDT4 - MinGW Makefiles -DBUILDSTATIC=1 -DBOOST_CUSTOM=1 -DBoost_INCLUDE_DIRS=C:\blender_svn\lib\windows\boost\include\ -DBoost_LIBRARY_DIRS=C:\blender_svn\lib\windows\boost\lib -DBoost_LIBRARIES=boost_date_time-mgw45-mt-1_47;boost_filesystem-mgw45-mt-1_47;boost_thread-mgw45-mt-1_47;boost_regex-mgw45-mt-1_47;boost_system-mgw45-mt-1_47 -DILMBASE_INCLUDE_DIR=C:\blender_svn\lib\windows\gcc\openexr\include -DOPENEXR_INCLUDE_DIR=C:\blender_svn\lib\windows\gcc\openexr\include -DZLIB_INCLUDE_DIR=C:\blender_svn\lib\windows\zlib\include -DZLIB_LIBRARY=C:\blender_svn\lib\windows\zlib\lib\libz.a -DPNG_LIBRARY=C:\blender_svn\lib\windows\png\lib\libpng.a -DPNG_PNG_INCLUDE_DIR=C:\blender_svn\lib\windows\png\include -DJPEG_LIBRARY=C:\blender_svn\lib\windows\jpeg\lib\libjpeg.lib -DJPEG_INCLUDE_DIR=C:\blender_svn\lib\windows\jpeg\include -DTIFF_LIBRARY=C:\blender_svn\lib\windows\tiff\lib\libtiff.lib -DTIFF_INCLUDE_DIR=C:\blender_svn\lib\windows\tiff\include -DCMAKE_INSTALL_PREFIX=C:\blender_svn\lib\windows\openimageio Not there yet, and I am getting some warnings: -- Project source dir = C:/blender_svn/oiio/src -- Project build dir = C:/Users/Psy-Fi/workspace/oiio -- Building with thread support -- Setting Namespace to: OpenImageIO -- CMAKE_SYSTEM_NAME = Windows -- CMAKE_SYSTEM_VERSION = 6.1 -- CMAKE_SYSTEM_PROCESSOR = x86 -- Windows! -- platform = windows -- THIRD_PARTY_TOOLS_HOME = unknown -- SPECIAL_COMPILE_FLAGS = -- ILMBASE_VERSION = 1.0.1 -- ILMBASE_HOME = unknown -- OPENEXR_VERSION = 1.6.1 -- OPENEXR_HOME = unknown -- BOOST_ROOT -- Boost found true -- Boost version -- Boost include dirs C:\blender_svn\lib\windows\boost\include\ -- Boost library dirs C:\blender_svn\lib\windows\boost\lib -- Boost libraries libboost_date_time-mgw45-mt-1_47.a;libboost_filesystem-mgw45-mt-1_47.a;libboost_thread-mgw45-mt-1_47.a;libboost_regex-mgw45-mt-1_47.a;libboost_system-mgw45-mt-1_47.a -- Boost_python_FOUND -- Boost python support not found -- will not build python components! -- OPENGL_FOUND=TRUE USE_OPENGL=ON -- QT4_FOUND= -- QT_INCLUDES= -- QT_LIBRARIES= -- GLEW not found -- Looking for system HDF5 -- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) -- HDF5_FOUND=FALSE -- HDF5_INCLUDE_DIRS=HDF5_CXX_INCLUDE_DIR-NOTFOUND -- HDF5_C_LIBRARIES= -- HDF5_CXX_LIBRARIES= -- HDF5_LIBRARIES=debug;HDF5_hdf5_cpp_LIBRARY_DEBUG-NOTFOUND;HDF5_hdf5_hl_LIBRARY_DEBUG-NOTFOUND;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND;optimized;HDF5_hdf5_cpp_LIBRARY_RELEASE-NOTFOUND;HDF5_hdf5_hl_LIBRARY_RELEASE-NOTFOUND;HDF5_hdf5_LIBRARY_RELEASE-NOTFOUND -- HDF5_LIBRARY_DIRS= -- Field3d will not be used -- Could NOT find Jasper (missing: JASPER_LIBRARY JASPER_INCLUDE_DIR) -- Jasper not found: jpeg2000 plugin will not be built -- Field3D plugin will not be built -- WARNING: No QT/OpenGL -- 'iv' will not be built! -- Create version.h from version.h.in -- Did not find C:/blender_svn/oiio/src/../../bmpsuite -- - Will not run tests bmp -- - You can find it at http://entropymine.com/jason/bmpsuite/bmpsuite.zip -- Did not find C:/blender_svn/oiio/src/../../libtiffpic -- - Will not run tests tiff-suite;tiff-depths -- - You can find it at http://www.remotesensing.org/libtiff/images.html -- Did not find C:/blender_svn/oiio/src/../../openexr-images-1.5.0 -- - Will not run tests openexr-suite;openexr-multires;openexr-chroma -- - You can find it at http://www.openexr.com/downloads.html -- Did not find C:/blender_svn/oiio/src/../../j2kp4files_v1_5 -- - Will not run tests jpeg2000 -- - You can find it at http://www.crc.ricoh.com/~gormish/jpeg2000conformance/ -- Did not find C:/blender_svn/oiio/src/../../TGAUTILS -- - Will not run tests targa-tgautils -- - You can find it at http://tgautils.inequation.org/ -- Did not find C:/blender_svn/oiio/src/../../fits-images -- - Will not run tests fits -- - You can find it at http://www.cv.nrao.edu/fits/data/tests/ -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Psy-Fi/workspace/oiio ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles MinGW compilation
Hi, 2011/9/12 Αντώνης Ρυακιωτάκης kal...@gmail.com: Hi brecht, excellent! By the way, what configuration enable flags do you use with cmake when compiling? I use the following: The build flags used are in svn: https://svn.blender.org/svnroot/bf-blender/trunk/lib/windows/openimageio/build.bat Not there yet, and I am getting some warnings: I can't find anything problematic in these warnings, seems the same as I had when compiling, not all plugins or tests are needed. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] More branches ready for review!
There's a whole bunch in my back yard you can kill if you want. :) They eat my garden... :( On Fri, Sep 9, 2011 at 8:22 PM, Daniel Salazar - 3Developer.com zan...@gmail.com wrote: I will kill a bunny every day until the mdef acceleration patch is in trunk or gets a review! http://codereview.appspot.com/4529048/ Daniel Salazar patch liberation front On Fri, Sep 9, 2011 at 3:23 PM, Nathan Vegdahl ces...@cessen.com wrote: Hi guys, Just want to put in a plug for the radish branch (weight painting tools). I did testing during part of it's development as I was available, and even though it is seemingly only a few simple tools, in fact it makes weight painting in Blender a _great deal_ more tractable. Particularly the lock-vertex-group feature is absolutely invaluable. I can't speak to it from a code quality standpoint, but from a user/features standpoint I 100% get behind it. I wish I had these features during Sintel--it would have prevented a lot of hair loss. ;-) --Nathan On Thu, Sep 1, 2011 at 6:29 AM, Thomas Dinges blen...@dingto.org wrote: Then someone should make this branch merge ready! :) http://wiki.blender.org/index.php?title=User:Nicksaction=editredlink=1 Nick Samarin, are you available to monitor and perform a merge? (If approved) Am 01.09.2011 15:26, schrieb Benoit Bolsee: Let's not forget the reviewed, tested and documented branch 'Recast Detour' from GSoC 2010. Merging should be easy: it was in sync with trunk a couple of month ago. Date: Wed, 31 Aug 2011 18:37:24 +0200 From: Ton Roosendaalt...@blender.org Subject: [Bf-committers] More branches ready for review! To: bf-blender developersbf-committers@blender.org Message-ID:be5447a8-2eae-4d1b-ad7c-dc323bed3...@blender.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi, Three GSoC developers have submitted their work as stable for 2.60 too: - Weighting tools - Dynamic Paint - International UI I've made an overview of all logs from the students here: http://code.blender.org/index.php/2011/08/google-summer-of-cod e-round-up/ (Marked projects 'R' for review :) Today is official deadline for people to submit branches or (larger) patches for inclusion oj our 2.60 target list. We'll do bi-monthly releases anyway, let's not make it too hard for us! Thanks, -Ton- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ 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 ___ 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
