Re: [Bf-committers] New Developer Meeting minutes
Hi Erwin, Erwin Coumans schrieb: Andrea, I tested current trunk on Windows and cmake debug build and release just compiles and runs fine, if you use default settings. Well, the default settings have only part of the features enabled. What if I want to debug/test these? Did you change any cmake defaults (such as enabling OpenCollada which is OFF by default)? Yes, I had OpenCollada enabled, it works fine with the debug build in the projectfiles, so why shouldn't it work with the cmake files? Did you file an issue with details in the bug tracker (with full callstack at crash)? not yet, because I didn't have much information. As far as I remember there wasn't even a call stack, because the application refused to start up. It crashed while loading the dlls at startup. Cheers, Andrea ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
I have also been using the CMake files with MSVC for the past year or so in Debug and Release. It takes a bit of tweaking, but so do most build systems. I also think scons is fantastic for getting a build up quickly and simply, but as many people have pointed out project files are great for development. I think both CMake and Scons have a place right now, and I don't think anyone needs to be taking sides :) -Emmanuel p.s. I like vim and emacs too On Sun, Jan 17, 2010 at 9:37 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Ok, I got fed up with all the discussion about a broken cmake Win32 debug build, so I fixed it in svn revision 26055. The fix is to put 'debug' or 'optimized' before the library name. cmake OpenCollada is now enabled by default for a bit of testing. If other devs like to disable it again, it is trivial to switch ON to OFF again :-) SET(OPENCOLLADA_LIB debug OpenCOLLADASaxFrameworkLoader_d debug OpenCOLLADAFramework_d debug OpenCOLLADABaseUtils_d debug OpenCOLLADAStreamWriter_d debug MathMLSolver_d debug GeneratedSaxParser_d debug UTF_d debug xml2_d optimized OpenCOLLADASaxFrameworkLoader optimized OpenCOLLADAFramework optimized OpenCOLLADABaseUtils optimized OpenCOLLADAStreamWriter optimized MathMLSolver optimized GeneratedSaxParser optimized UTF optimized xml2 ) Are there any other outstanding cmake issues, or was the fuzz all about this OpenCollada issue? Thanks, Erwin 2010/1/17 Andrea Weikert and...@aweikert.de: Hi Erwin, Erwin Coumans schrieb: Andrea, I tested current trunk on Windows and cmake debug build and release just compiles and runs fine, if you use default settings. Well, the default settings have only part of the features enabled. What if I want to debug/test these? Did you change any cmake defaults (such as enabling OpenCollada which is OFF by default)? Yes, I had OpenCollada enabled, it works fine with the debug build in the projectfiles, so why shouldn't it work with the cmake files? Did you file an issue with details in the bug tracker (with full callstack at crash)? not yet, because I didn't have much information. As far as I remember there wasn't even a call stack, because the application refused to start up. It crashed while loading the dlls at startup. Cheers, Andrea ___ 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
Re: [Bf-committers] New Developer Meeting minutes
How about those projectfiles_vc9? A working cmake should make them redundant. It would be great if Andrea Weikert (Elubie) and Benoit could switch from manual updating those projectfiles_vc9 (and vc7) to cmake. That would help cmake in Blender quite a bit I think. Cheers, Erwin Out of curiosity: are any of the scons users using those projectfiles_vc9 (occasionally) on Windows? 2010/1/14 Benjamin Tolputt btolp...@internode.on.net: joe wrote: I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. And if the project files were updated along with the Scons build files - that is all well good. Seriously, all I am concerned about is the capability of extending debugging Blender in an IDE (namely MSVC XCode being a Windows/Mac guy for graphics). CMake has that by default, being the way it operates, were Scons to provide the project files either automatically or through the use of a command line parameter - I'd be all for it. The slower build time of Scons, while a niggle, is not the issue. It is the disconnect between using/editing Scons using an IDE that is causing myself and the developers I've talked to (an entire two of them :P ) grief. The build of a release version of Blender is not a daily thing. Updating the projects to the latest versions from SVN is such a common task. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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] New Developer Meeting minutes
I used to occasionally use the manually maintained project files, but then I learned that cmake could generate them and I've been using those since. Cheers, Mitchell Stokes (Moguri) On Sat, Jan 16, 2010 at 8:30 AM, Erwin Coumans erwin.coum...@gmail.com wrote: How about those projectfiles_vc9? A working cmake should make them redundant. It would be great if Andrea Weikert (Elubie) and Benoit could switch from manual updating those projectfiles_vc9 (and vc7) to cmake. That would help cmake in Blender quite a bit I think. Cheers, Erwin Out of curiosity: are any of the scons users using those projectfiles_vc9 (occasionally) on Windows? 2010/1/14 Benjamin Tolputt btolp...@internode.on.net: joe wrote: I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. And if the project files were updated along with the Scons build files - that is all well good. Seriously, all I am concerned about is the capability of extending debugging Blender in an IDE (namely MSVC XCode being a Windows/Mac guy for graphics). CMake has that by default, being the way it operates, were Scons to provide the project files either automatically or through the use of a command line parameter - I'd be all for it. The slower build time of Scons, while a niggle, is not the issue. It is the disconnect between using/editing Scons using an IDE that is causing myself and the developers I've talked to (an entire two of them :P ) grief. The build of a release version of Blender is not a daily thing. Updating the projects to the latest versions from SVN is such a common task. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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
Re: [Bf-committers] New Developer Meeting minutes
Yeah it's fairly common iirc. I do, and I know of at least two other devs who have done the same. I think the problem here is none of us have time to test cmake thoroughly to evaluate it, and I'm not sure how many other devs have had the same speed issues I have, that motivates me to evaluate cmake in the first place.. Joe On Sat, Jan 16, 2010 at 8:30 AM, Erwin Coumans erwin.coum...@gmail.com wrote: How about those projectfiles_vc9? A working cmake should make them redundant. It would be great if Andrea Weikert (Elubie) and Benoit could switch from manual updating those projectfiles_vc9 (and vc7) to cmake. That would help cmake in Blender quite a bit I think. Cheers, Erwin Out of curiosity: are any of the scons users using those projectfiles_vc9 (occasionally) on Windows? 2010/1/14 Benjamin Tolputt btolp...@internode.on.net: joe wrote: I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. And if the project files were updated along with the Scons build files - that is all well good. Seriously, all I am concerned about is the capability of extending debugging Blender in an IDE (namely MSVC XCode being a Windows/Mac guy for graphics). CMake has that by default, being the way it operates, were Scons to provide the project files either automatically or through the use of a command line parameter - I'd be all for it. The slower build time of Scons, while a niggle, is not the issue. It is the disconnect between using/editing Scons using an IDE that is causing myself and the developers I've talked to (an entire two of them :P ) grief. The build of a release version of Blender is not a daily thing. Updating the projects to the latest versions from SVN is such a common task. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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
Re: [Bf-committers] New Developer Meeting minutes
I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. Joe On Thu, Jan 14, 2010 at 2:28 PM, Mike Pan madoni...@gmail.com wrote: As mentioned before, I think one of the key benefit of cmake is the ability to generate solution/project files. This might be not be a huge deal to seasoned coders, but for beginner coders who just wants to explore the Blender source code a bit, having an IDE like Visual Studio really helps. -mike On Thu, Jan 14, 2010 at 2:21 PM, joe joe...@gmail.com wrote: Sounds like us scons people need to try out cmake. See how good it is. I don't have time now, but will try to get to it. Also need to look at how easy it is to maintain, that's one of the really nice things about scons. Joe On Thu, Jan 14, 2010 at 6:04 AM, Miguel A. Figueroa-Villanueva migu...@ieee.org wrote: On Tue, Jan 12, 2010 at 2:51 AM, Mats Holmberg wrote: On 12.1.2010, at 8.39, Nathan Letwory wrote: 2010/1/12 Erwin Coumans: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Just to comment on this: I know nothing about the hassle that is required for maintaining any of these systems, but from a Blender user standpoint scons is very easy to use. As Nathan said, I do svn up python scons/scons.py and that's all that's ever needed. During the years, I haven't seen anything being even close to that kind of ease of use. Dont' take that away, please! -mats I'm not a community member, so please pardon the intrusion (I am interested in blender, have compiled it with the cmake system, and I am looking forward to contributing to it in the future, but haven't had the time yet...). However, I just started reading this thread and it seems to me there is a lot of resistance, as Erwin mentions, to cmake without real justification. Although I understand the why, I think the arguments against CMake are not well founded. Most, if not all, of the problems that have been mentioned are related to rules either not updated or wrongly written in the CMakeLists.txt. These are issues with the build system maintainers not with CMake's capabilities. With properly written and maintained CMake files you would have both a very powerful command line based system and an equally powerful IDE based system. For example, the argument of ease of use can certainly be used as a positive aspect of scons, but I find it to be unfounded when arguing against CMake. That is because I do the following version of svn up python scons/scons.py to build my projects, not only on Ubuntu but on Windows: ctest -S simple_ctest_script.cmake With a small script ctest will: update (from svn,cvs,hg,etc), configure, build, test, and submit the build to a dashboard (or any subset of these steps). Again, I don't want to argue against scons, but I think that arguments against cmake are not really flaws of cmake but rather bad experiences because of not knowing how to do things (either from part of the user or the build system maintainer) and not giving it enough of a chance. I think that if the blender community really gives cmake a chance, it will not be dissapointed with the clean, simple, and flexible product that cmake can provide. Whether it should then replace, coexist, etc. with scons is a discussion that I wouldn't feel comfortable providing any input on. Just my $0.02, --Miguel ___ 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
Re: [Bf-committers] New Developer Meeting minutes
joe wrote: I use msvc for source editing and debugging, and scons for compiling. Build systems don't have to replace project files, I use scons mostly because there's more control that way for what I do. And if the project files were updated along with the Scons build files - that is all well good. Seriously, all I am concerned about is the capability of extending debugging Blender in an IDE (namely MSVC XCode being a Windows/Mac guy for graphics). CMake has that by default, being the way it operates, were Scons to provide the project files either automatically or through the use of a command line parameter - I'd be all for it. The slower build time of Scons, while a niggle, is not the issue. It is the disconnect between using/editing Scons using an IDE that is causing myself and the developers I've talked to (an entire two of them :P ) grief. The build of a release version of Blender is not a daily thing. Updating the projects to the latest versions from SVN is such a common task. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
2010/1/12 Erwin Coumans erwin.coum...@gmail.com: In any case, lets just make sure Blender gets better, ok? Improving cmake is a great start in making Blender better. And so is improving SCons. /Nathan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
Committed in svn 25921.
CMake build worked on Mac before after the patch :)
Damien
Le 12 janv. 2010 à 03:48, lguillaume a écrit :
Just to say that I successfully made a 64 bits compilation of blender with
vc2010 beta 2010 and cmake 2.8.
Can anyone put the patch for correcting quicktime dir in cmake (anyone who
can test if it does not break on mac) :
Index: source/blender/makesrna/intern/CMakeLists.txt
===
--- source/blender/makesrna/intern/CMakeLists.txt(revision 25905)
+++ source/blender/makesrna/intern/CMakeLists.txt(working copy)
@@ -63,7 +63,7 @@
ENDIF(WITH_DDS)
IF(WITH_QUICKTIME)
-SET(INC ${INC} ../../quicktime)
+SET(INC ${INC} ../../quicktime)
ADD_DEFINITIONS(-DWITH_QUICKTIME)
ENDIF(WITH_QUICKTIME)
___
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] New Developer Meeting minutes
On 12.1.2010, at 8.39, Nathan Letwory wrote: 2010/1/12 Erwin Coumans erwin.coum...@gmail.com: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Just to comment on this: I know nothing about the hassle that is required for maintaining any of these systems, but from a Blender user standpoint scons is very easy to use. As Nathan said, I do svn up python scons/scons.py and that's all that's ever needed. During the years, I haven't seen anything being even close to that kind of ease of use. Dont' take that away, please! -mats ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
If there's people willing to maintain for their own respective compile systems, I don't see the issue. I suppose collectively, our efforts are split, but that's the nature of open source projects. Different people with different systems, goals, etc. Mike Belanger ( Mikahl ) www.watchmike.ca On 2010-01-12, at 12:51 AM, Mats Holmberg wrote: On 12.1.2010, at 8.39, Nathan Letwory wrote: 2010/1/12 Erwin Coumans erwin.coum...@gmail.com: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Just to comment on this: I know nothing about the hassle that is required for maintaining any of these systems, but from a Blender user standpoint scons is very easy to use. As Nathan said, I do svn up python scons/scons.py and that's all that's ever needed. During the years, I haven't seen anything being even close to that kind of ease of use. Dont' take that away, please! -mats ___ 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] New Developer Meeting minutes
When I generate an MSVC project with CMake, the header files are in the project, dependencies seem to be taken into account correctly, wildcards are used to automatically add/remove files, .. is there an actual problem here? Brecht. On Sun, Jan 10, 2010 at 10:53 PM, Erwin Coumans erwin.coum...@gmail.com wrote: You can avoid the work by adding a GLOB * wildcard for header files, but explicitly specifying every individual file seems recommended indeed. Once you have the cmake project up and running, you usually only add a few .cpp or .h files at a time, so the incremental effort usually isn't much. This doesn't seem to be a good reason to favor scons over cmake. Thanks, Erwin 2010/1/10 joe joe...@gmail.com Yeek. That's horrible. I wonder how hard would it be to write some utility code for the cmakefiles that scans for #include statements. This sort of thing is exactly why I stick with scons, despite it's horrific speed problems. :-/ I'm even tempted to rewrite our scons files to use waf instead sometimes. Joe ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
The stackoverflow answer seem to confirm there are some dependencies and performance issues with GLOB. I'm interested to hear what the 'official' recommendation is by the cmake developers. Cheers, Erwin 2010/1/11 José Ignacio jose.cyb...@gmail.com On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans erwin.coum...@gmail.com wrote: The is no problem using GLOB with a wildcard, as I mentioned at least times in this thread ;) But explicitly listing each file seems recommended, I forgot why. Perhaps GLOB needs to search for (potential) new headerfiles, every time you build and a .cpp changed (slowing down things unnecesarily)? Perhaps reading the docs, using google or asking on the cmake mailingslist will tell why GLOB can better be avoided in CMakeLists.txt? IIRC, if you use globbing and added a new file after you build for the first time, it won't take it into account for the next call of make unless you touch the CMakeLists.txt file or clear the cache and rebuild. (though maybe that behavior changed on newer versions of cmake) oh, a google search gave me this link: http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake Cheers, Erwin ___ 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] New Developer Meeting minutes
From the CMake mailinglist: http://www.cmake.org/pipermail/cmake/2009-July/030535.html The problem with globbing is that CMake has no way to determine that new source (or header) files were added to a directory, other than ALWAYS running when someone types 'make' (or the VS equivalent). This is not really desirable behaviour, because oftentimes no new files will have been added. And therefore, that's not how CMake behaves. So, in general, when using globbing, YOU are responsible for rerunning CMake whenever you've added a source file. Otherwise you run the risk of the new file not being compiled. Furthermore, you might accidentally compile sources that were just lying around in your directory as test code. Deletion of sources can also cause interesting effects if you create a library, because the object will remain in that library until you (manually) remove and recreate the library. I hope my examples convinced you enough that globbing is (in general) a bad idea. Re-running cmake each time to recognize new/deleted headerfiles doesn't seem efficient, but if developers prefer ease of use at the cost of some performance you might want to use GLOB. Just don't complain that dependencies don't reliably work, or that cmake is a bit slow :-) I follow the advice of the CMake developers for the Bullet project, and I'm happy with it. 2010/1/11 Erwin Coumans erwin.coum...@gmail.com The stackoverflow answer seem to confirm there are some dependencies and performance issues with GLOB. I'm interested to hear what the 'official' recommendation is by the cmake developers. Cheers, Erwin 2010/1/11 José Ignacio jose.cyb...@gmail.com On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans erwin.coum...@gmail.com wrote: The is no problem using GLOB with a wildcard, as I mentioned at least times in this thread ;) But explicitly listing each file seems recommended, I forgot why. Perhaps GLOB needs to search for (potential) new headerfiles, every time you build and a .cpp changed (slowing down things unnecesarily)? Perhaps reading the docs, using google or asking on the cmake mailingslist will tell why GLOB can better be avoided in CMakeLists.txt? IIRC, if you use globbing and added a new file after you build for the first time, it won't take it into account for the next call of make unless you touch the CMakeLists.txt file or clear the cache and rebuild. (though maybe that behavior changed on newer versions of cmake) oh, a google search gave me this link: http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake Cheers, Erwin ___ 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] New Developer Meeting minutes
On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Just don't complain that dependencies don't reliably work, or that cmake is a bit slow :-) I follow the advice of the CMake developers for the Bullet project, and I'm happy with it. This isn't convincing me that CMake is any better then anything else; it may generate project files, but I don't use that, and our scons setup could be setup to do the same thing as well. I care very much about dependencies, mostly because I can't afford to do clean builds as often as is often necessary in a build system with unreliable dependency updates (old, crappy hardware is just too slow to do that). Joe On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: From the CMake mailinglist: http://www.cmake.org/pipermail/cmake/2009-July/030535.html The problem with globbing is that CMake has no way to determine that new source (or header) files were added to a directory, other than ALWAYS running when someone types 'make' (or the VS equivalent). This is not really desirable behaviour, because oftentimes no new files will have been added. And therefore, that's not how CMake behaves. So, in general, when using globbing, YOU are responsible for rerunning CMake whenever you've added a source file. Otherwise you run the risk of the new file not being compiled. Furthermore, you might accidentally compile sources that were just lying around in your directory as test code. Deletion of sources can also cause interesting effects if you create a library, because the object will remain in that library until you (manually) remove and recreate the library. I hope my examples convinced you enough that globbing is (in general) a bad idea. Re-running cmake each time to recognize new/deleted headerfiles doesn't seem efficient, but if developers prefer ease of use at the cost of some performance you might want to use GLOB. 2010/1/11 Erwin Coumans erwin.coum...@gmail.com The stackoverflow answer seem to confirm there are some dependencies and performance issues with GLOB. I'm interested to hear what the 'official' recommendation is by the cmake developers. Cheers, Erwin 2010/1/11 José Ignacio jose.cyb...@gmail.com On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans erwin.coum...@gmail.com wrote: The is no problem using GLOB with a wildcard, as I mentioned at least times in this thread ;) But explicitly listing each file seems recommended, I forgot why. Perhaps GLOB needs to search for (potential) new headerfiles, every time you build and a .cpp changed (slowing down things unnecesarily)? Perhaps reading the docs, using google or asking on the cmake mailingslist will tell why GLOB can better be avoided in CMakeLists.txt? IIRC, if you use globbing and added a new file after you build for the first time, it won't take it into account for the next call of make unless you touch the CMakeLists.txt file or clear the cache and rebuild. (though maybe that behavior changed on newer versions of cmake) oh, a google search gave me this link: http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake Cheers, Erwin ___ 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
Re: [Bf-committers] New Developer Meeting minutes
it (cmake) may generate project files, but I don't use that It sounds a little bit selfish, there are many developers who want to use project files. and our scons setup could be setup to do the same thing as well. Can scons create decent MSVC and Xcode project files? Who maintains such project generation? Thanks, Erwin 2010/1/11 joe joe...@gmail.com Does it run automatically or do you have to run it yourself? Joe On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton ideasma...@gmail.com wrote: @joe, From my experience cmake doesnt require you to do more clean builds then scons. The only thing is is dependencies change cmake . needs to run again in the build dir, building after only does a partial build like scons. If I understand this correctly, only generating the Makefiles is slower with GLOB, not running the subsequent make's (else it should find the new C/H files also). re: defining all files, not having to re-run cmake . would be nice but Im not that fussed, if we only used CMake, maintaining the file lists might not be so hard, but is some dev adds a file and they use another build system its annoying for them to have to update the CMake files (think msvc project files). On Mon, Jan 11, 2010 at 10:41 PM, joe joe...@gmail.com wrote: On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Just don't complain that dependencies don't reliably work, or that cmake is a bit slow :-) I follow the advice of the CMake developers for the Bullet project, and I'm happy with it. This isn't convincing me that CMake is any better then anything else; it may generate project files, but I don't use that, and our scons setup could be setup to do the same thing as well. I care very much about dependencies, mostly because I can't afford to do clean builds as often as is often necessary in a build system with unreliable dependency updates (old, crappy hardware is just too slow to do that). Joe On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: From the CMake mailinglist: http://www.cmake.org/pipermail/cmake/2009-July/030535.html The problem with globbing is that CMake has no way to determine that new source (or header) files were added to a directory, other than ALWAYS running when someone types 'make' (or the VS equivalent). This is not really desirable behaviour, because oftentimes no new files will have been added. And therefore, that's not how CMake behaves. So, in general, when using globbing, YOU are responsible for rerunning CMake whenever you've added a source file. Otherwise you run the risk of the new file not being compiled. Furthermore, you might accidentally compile sources that were just lying around in your directory as test code. Deletion of sources can also cause interesting effects if you create a library, because the object will remain in that library until you (manually) remove and recreate the library. I hope my examples convinced you enough that globbing is (in general) a bad idea. Re-running cmake each time to recognize new/deleted headerfiles doesn't seem efficient, but if developers prefer ease of use at the cost of some performance you might want to use GLOB. 2010/1/11 Erwin Coumans erwin.coum...@gmail.com The stackoverflow answer seem to confirm there are some dependencies and performance issues with GLOB. I'm interested to hear what the 'official' recommendation is by the cmake developers. Cheers, Erwin 2010/1/11 José Ignacio jose.cyb...@gmail.com On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans erwin.coum...@gmail.com wrote: The is no problem using GLOB with a wildcard, as I mentioned at least times in this thread ;) But explicitly listing each file seems recommended, I forgot why. Perhaps GLOB needs to search for (potential) new headerfiles, every time you build and a .cpp changed (slowing down things unnecesarily)? Perhaps reading the docs, using google or asking on the cmake mailingslist will tell why GLOB can better be avoided in CMakeLists.txt? IIRC, if you use globbing and added a new file after you build for the first time, it won't take it into account for the next call of make unless you touch the CMakeLists.txt file or clear the cache and rebuild. (though maybe that behavior changed on newer versions of cmake) oh, a google search gave me this link: http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake Cheers, Erwin ___ 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] New Developer Meeting minutes
That's what I was trying to figure out, whether it's as good as scons or not. It sounds like it might be comparable, so I'm going to try it as soon as I get time. If it is, I'll be very happy, since for all it's ease of use and maintenance, scons really is super slow. Joe On Mon, Jan 11, 2010 at 2:30 PM, Erwin Coumans erwin.coum...@gmail.com wrote: ah, ok, I would have been interested in open source scons project file generation. (actually at Havok we had scons create cross-platform project files, but these extensions were kept in-house) As far as I know, cmake works very well for both command line and projectfiles. I still haven't heard a convincing argument of scons features that cmake doesn't have. GLOB works fine (even though manual is better) How is cmake not good enough? Thanks, Erwin 2010/1/11 joe joe...@gmail.com I wasn't saying we should abandon support for projectfiles. My point is that cmake must perform on the command line build workflow as well as project file workflows. And that support for projectfiles doesn't make it great for command line (and vice versa). I wasn't advocating generating project files from our scons system, heh. I'm all for replacing scons, actually, either by rewriting our scons wrapper and infrastructure to use waf, or replacing it with cmake if cmake is good enough. Joe On Mon, Jan 11, 2010 at 2:10 PM, Erwin Coumans erwin.coum...@gmail.com wrote: it (cmake) may generate project files, but I don't use that It sounds a little bit selfish, there are many developers who want to use project files. and our scons setup could be setup to do the same thing as well. Can scons create decent MSVC and Xcode project files? Who maintains such project generation? Thanks, Erwin 2010/1/11 joe joe...@gmail.com Does it run automatically or do you have to run it yourself? Joe On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton ideasma...@gmail.com wrote: @joe, From my experience cmake doesnt require you to do more clean builds then scons. The only thing is is dependencies change cmake . needs to run again in the build dir, building after only does a partial build like scons. If I understand this correctly, only generating the Makefiles is slower with GLOB, not running the subsequent make's (else it should find the new C/H files also). re: defining all files, not having to re-run cmake . would be nice but Im not that fussed, if we only used CMake, maintaining the file lists might not be so hard, but is some dev adds a file and they use another build system its annoying for them to have to update the CMake files (think msvc project files). On Mon, Jan 11, 2010 at 10:41 PM, joe joe...@gmail.com wrote: On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: Just don't complain that dependencies don't reliably work, or that cmake is a bit slow :-) I follow the advice of the CMake developers for the Bullet project, and I'm happy with it. This isn't convincing me that CMake is any better then anything else; it may generate project files, but I don't use that, and our scons setup could be setup to do the same thing as well. I care very much about dependencies, mostly because I can't afford to do clean builds as often as is often necessary in a build system with unreliable dependency updates (old, crappy hardware is just too slow to do that). Joe On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans erwin.coum...@gmail.com wrote: From the CMake mailinglist: http://www.cmake.org/pipermail/cmake/2009-July/030535.html The problem with globbing is that CMake has no way to determine that new source (or header) files were added to a directory, other than ALWAYS running when someone types 'make' (or the VS equivalent). This is not really desirable behaviour, because oftentimes no new files will have been added. And therefore, that's not how CMake behaves. So, in general, when using globbing, YOU are responsible for rerunning CMake whenever you've added a source file. Otherwise you run the risk of the new file not being compiled. Furthermore, you might accidentally compile sources that were just lying around in your directory as test code. Deletion of sources can also cause interesting effects if you create a library, because the object will remain in that library until you (manually) remove and recreate the library. I hope my examples convinced you enough that globbing is (in general) a bad idea. Re-running cmake each time to recognize new/deleted headerfiles doesn't seem efficient, but if developers prefer ease of use at the cost of some performance you might want to use GLOB. 2010/1/11 Erwin Coumans erwin.coum...@gmail.com The stackoverflow answer seem to confirm there are some
Re: [Bf-committers] New Developer Meeting minutes
Erwin Coumans wrote: Have you seriously tried to find a solution? I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Agreed. There seems to be quite a few posts *looking for* problems with CMake... I have not found any problems with CMake (provided I've set the right options) and the capability of having a standard make along with XCode MSVC projects (I compile on all three platforms, though only use Blender on Win/Mac) kind of tilts things in CMake's favour. That is not to say Scons is bad, I find it pretty good too - just not as easy to use with an IDE. I just don't understand the animosity there appears to be for CMake. -- Regards, Benjamin Tolputt Analyst Programmer ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
Well, it's had a rough start and some of us are wary of using it exclusively without assurance it's not going to be a step backwards :) I also think the fact that it generates makefiles makes some of us initially nervous, since makefiles are usually synonymous with immensely painful and difficult to maintain. Joe On Mon, Jan 11, 2010 at 3:08 PM, Benjamin Tolputt btolp...@internode.on.net wrote: Erwin Coumans wrote: Have you seriously tried to find a solution? I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Agreed. There seems to be quite a few posts *looking for* problems with CMake... I have not found any problems with CMake (provided I've set the right options) and the capability of having a standard make along with XCode MSVC projects (I compile on all three platforms, though only use Blender on Win/Mac) kind of tilts things in CMake's favour. That is not to say Scons is bad, I find it pretty good too - just not as easy to use with an IDE. I just don't understand the animosity there appears to be for CMake. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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] New Developer Meeting minutes
But of course I'm going to look into it more now, I would love to be able to not have to deal with the sheer slowness of scons. Joe On Mon, Jan 11, 2010 at 3:26 PM, joe joe...@gmail.com wrote: Well, it's had a rough start and some of us are wary of using it exclusively without assurance it's not going to be a step backwards :) I also think the fact that it generates makefiles makes some of us initially nervous, since makefiles are usually synonymous with immensely painful and difficult to maintain. Joe On Mon, Jan 11, 2010 at 3:08 PM, Benjamin Tolputt btolp...@internode.on.net wrote: Erwin Coumans wrote: Have you seriously tried to find a solution? I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Agreed. There seems to be quite a few posts *looking for* problems with CMake... I have not found any problems with CMake (provided I've set the right options) and the capability of having a standard make along with XCode MSVC projects (I compile on all three platforms, though only use Blender on Win/Mac) kind of tilts things in CMake's favour. That is not to say Scons is bad, I find it pretty good too - just not as easy to use with an IDE. I just don't understand the animosity there appears to be for CMake. -- Regards, Benjamin Tolputt Analyst Programmer ___ 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] New Developer Meeting minutes
Selon Benjamin Tolputt btolp...@internode.on.net: Erwin Coumans wrote: Have you seriously tried to find a solution? I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Agreed. There seems to be quite a few posts *looking for* problems with CMake... I have not found any problems with CMake (provided I've set the right options) and the capability of having a standard make along with XCode MSVC projects (I compile on all three platforms, though only use Blender on Win/Mac) kind of tilts things in CMake's favour. That is not to say Scons is bad, I find it pretty good too - just not as easy to use with an IDE. I just don't understand the animosity there appears to be for CMake. If cmake was so marvelous, it should work easily on any system but it don't without serious search. That's what I experimented and others users that do not post on this list too ( LG knows that it's true). Another point : you are all saying that have to do two things ( build a projet with Cmake and after load this project in Visual Studio to generate a solution) is faster and easier than just do one thing (build the sources with Scons), and I really do not unerstand that. My last message for the resistance, regards jms ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
2010/1/12 Erwin Coumans erwin.coum...@gmail.com: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Obviously I'm biased as our SCons build system creator and maintainer as it currently stands, but it works on all our supported platforms. Builds without too much fuss for new and old developers. And for me as release builder on Windows it does all I need it to do without having to use any extra steps. I run scons and voilà, new release stuff ready. I won't mind seeing SCons go IF there is a system that does all what SCons currently does (if it does more, yay). Currently that is not the situation, and *I* am *not* going to invest time in Yet Another Build system, until someone else has done exactly that. I have so much time invested in the system, and I believe that our SCons system is more than adequate for our developers that I don't see the need to start looking into other systems. Waf I've checked somewhat, but heck, the first rewrite of SCons into what it currently is already took almost half a year (instead of the 3 days I originally estimated), and since then it has had many improvements (and yes, it can do with more improvements, but that we can say of everything we have). At times, when I look at this thread and related discussion in IRC, (glorifying CMake and downtalking SCons), I can become a little angry. There's a lot talk for CMake, wondering why people are against it, but then the people who start the talks don't do anything about it. I think that doing that is not beneficial for us and just needlessly generates noise on our mailing list. Consider this message part of that stupid noise. If you want to see changes: contribute the damn changes, don't just talk and leave and come back to wonder why nothing has changed. (And do make sure your patch with the great new build system does what our SCons system does now). I will look into having SCons create VS project files (XCode I know nothing of, so that'll have to wait) - there's support available for that in SCons, but there are some fixes needed for it to be useful in our case. In any case, lets just make sure Blender gets better, ok? I continue with my Scons efforts until someone comes with a better system in all aspects. /Nathan ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I have not asked mentioned to get rid of scons, but asked to fix cmake, because cmake can create MSVC, XCode and other project files. scons cannot do that, and according to Campbell it is slower than cmake. In any case, lets just make sure Blender gets better, ok? Improving cmake is a great start in making Blender better. Thanks, Erwin 2010/1/11 Nathan Letwory jesterk...@letwory.net 2010/1/12 Erwin Coumans erwin.coum...@gmail.com: I'm surprised of so much resistance among the Blender developers to such a nice build system as cmake. Thanks, Erwin We can also reverse the question - we have a very nice and working SCons system. Why would you want to get rid of the nice system I created? I'm surprised at the resistance among certain people to such a nice build system as SCons Obviously I'm biased as our SCons build system creator and maintainer as it currently stands, but it works on all our supported platforms. Builds without too much fuss for new and old developers. And for me as release builder on Windows it does all I need it to do without having to use any extra steps. I run scons and voilà, new release stuff ready. I won't mind seeing SCons go IF there is a system that does all what SCons currently does (if it does more, yay). Currently that is not the situation, and *I* am *not* going to invest time in Yet Another Build system, until someone else has done exactly that. I have so much time invested in the system, and I believe that our SCons system is more than adequate for our developers that I don't see the need to start looking into other systems. Waf I've checked somewhat, but heck, the first rewrite of SCons into what it currently is already took almost half a year (instead of the 3 days I originally estimated), and since then it has had many improvements (and yes, it can do with more improvements, but that we can say of everything we have). At times, when I look at this thread and related discussion in IRC, (glorifying CMake and downtalking SCons), I can become a little angry. There's a lot talk for CMake, wondering why people are against it, but then the people who start the talks don't do anything about it. I think that doing that is not beneficial for us and just needlessly generates noise on our mailing list. Consider this message part of that stupid noise. If you want to see changes: contribute the damn changes, don't just talk and leave and come back to wonder why nothing has changed. (And do make sure your patch with the great new build system does what our SCons system does now). I will look into having SCons create VS project files (XCode I know nothing of, so that'll have to wait) - there's support available for that in SCons, but there are some fixes needed for it to be useful in our case. In any case, lets just make sure Blender gets better, ok? I continue with my Scons efforts until someone comes with a better system in all aspects. /Nathan ___ 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] New Developer Meeting minutes
Yes it does. You just need to make sure that the headerfiles are included in the CMakeLists.txt Are the dependencies broken in cmake generated unix makefiles? If so, it could and should be fixed U think. In out Bullet library it works all fine. Thanks, Erwin Sent from my iPhone On Jan 7, 2010, at 6:28, joe joe...@gmail.com wrote: Do the makefiles it generate handle dependency updates correctly? That's the big reason I use scons, and why it's survived I think. Joe On Thu, Jan 7, 2010 at 6:22 AM, Erwin Coumans erwin.coum...@gmail.com wrote: The fact that cmake can create visual studio projects, Xcode projects and makefiles should make scons, make and manual msvc project maintenance obsolete. It is a pity people don't maintain/fix cmake. Thanks, Erwin Sent from my iPhone On Jan 7, 2010, at 1:56, Campbell Barton ideasma...@gmail.com wrote: The build system topic took most of the meeting or so and I hope we dont let this happen again or the new dev meetings will get very uninteresting. Please next time try to avoid arguing about stupid topics like this while we are trying to give basic info to new devs. I think topics like this just need better WIKI Docs and not discussion with new devs. (Or limit to 5min intro) Hi Nathan, I didnt mean to say scons does full rebuilds, just that its slower if you do quick rebuilds. SCons is great to get a build running however for development Im now quite convinced its not the way to go. When nothing needs building, CMake's Makefiles take around 2.1 seconds on my system. Scons takes between 30 and 40 seconds. Time to compile and link with one change with CMake made is 6.8 second or so. I have tried optimizing scons before and I can get moderate speedups... but it still doesnt get close to CMake's. SCons with BF_QUICK gives more acceptable times but this means I waste time thinking about what libs to build and occasionally getting it wrong and having to find out why BF_QUICK failed. I appreciate your work on scons and dont mean to belittle it but with CMake so much faster for rebuilds I feel justified in recommending CMake over scons for people who intend to build often. - Campbell On Thu, Jan 7, 2010 at 8:46 AM, Nathan Letwory jesterk...@letwory.net wrote: Roger Wickes wrote: We held our second monthly new developer meeting(http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings ) on Sunday, attracting x new developers to the Blender family. Minutes are here: http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings/2010-01-03rd . We discussed Build systems, Patch Submission, and Python, with a focus on Cmake versus Scons. Hi, great to see that the second new dev meeting has been held - too bad I couldn't be there, since SCons has been talked about, too. I feel I have to make a small comment though: SCons never does a full recompile, when it is not necessary (and it hardly ever is). So in that sense, SCons will also do incremental builds. Sure, it does read in the SConscripts, but *that is not equivalent to a complete rebuild*. It does pose some slight overhead when starting a build, but that should not be the reason to start favoring CMake over SCons. Again: SCons builds only what is needed. When doing a clean rebuild, (remove *everything* created by SCons/ CMake before doing your build), I assure you that you won't find useful differences in build times. I have started writing out docs on the SCons system on my blog http://www.letworyinteractive.com/b/building-blender-with-scons/ (see also the top navigation for more links). More info there will gradually be published as I get it all written out. It already contains good info on how the configuration of the system goes. /Nathan ___ 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 ___ 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] New Developer Meeting minutes
Not sure what dependency updates are exactly - if files are added you need to run cmake . in the build dir but aside from that I never had any dep propblems. I'm tempted to install Windows just to get rid of the MSVC Project files and have CMake create propper debug builds... it cant be that hard can it? @Martin, my experience with using scons and eclipse isnt so good, it works OK but a bit annoying to setup, I recall I needed to have eclipse call a shell script that called scons. Eclipse + Cmake is nicer, and takes the work out of setting up the project each time. especially if you want to switch to developing in branches for a bit. On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier the...@yahoo.com wrote: --- On Thu, 1/7/10, Erwin Coumans erwin.coum...@gmail.com wrote: New developers (and myself) can browse and debug code much easier in an IDE such as msvc, Xcode or K develop, in my opinion. And manual updating projectfiles is a waste of time. It's very easy to use Eclipse (with CDT) with scons. K Develop was pretty easy to setup too the last time I tried. There was no project files to update or anything. 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@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] New Developer Meeting minutes
cmake can create msvc and xcode projectfiles. scons cannot do this, and seems slower incremental builds (according to Campbell). This justifies fixing any remaining issues with cmake/CMakeLists.txt files I think. I'm tempted to install Windows just to get rid of the MSVC Project files and have CMake create propper debug builds... it cant be that hard can it? If you don't get to this, I'll have a look at it in a little while (have to wrap up Bullet 2.76 first) Thanks, Erwin 2010/1/7 Martin Poirier the...@yahoo.com --- On Thu, 1/7/10, Campbell Barton ideasma...@gmail.com wrote: @Martin, my experience with using scons and eclipse isnt so good, it works OK but a bit annoying to setup, I recall I needed to have eclipse call a shell script that called scons. You were doing it wrong then. The only thing you need to do is edit the build command, changing make for scons Potentially adding BF_FANCY=0 and BF_DEBUG=1 if those aren't in your user-config. Eclipse + Cmake is nicer, and takes the work out of setting up the project each time. especially if you want to switch to developing in branches for a bit. Setting up a new project takes less than 30s. If that's too long for you, you can just copy the .project from an existing branch if you want (regardless of the build engine used). Martin __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php ___ 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] New Developer Meeting minutes
Hy, Just giving my input as a (trying to be) new dev: CMake is in fact quicker for incremental build but scons is used buy a lot by people that just want to build svn, and I think there is a reason to this: It is simpler to get started with and most of the doc for building blender refer to scons. That beiing said cmake not complicated neither to do a quick compile from command line. I personnaly used scons for a long time before looking for an IDE with integrated debugger (I can get backtace from command line gdb but not more). Then I discovered Kdevelop4 with cmake support and everything works fine (just import CMake.list as a project). SVN, cmake configuration, code browser and gdb is all accessible from the ui out of the box. Much quicker than my old vim, scons, gdb, cscope way of working (exept for loading the project which takes some time). Xavier 2010/1/7 Campbell Barton ideasma...@gmail.com The build system topic took most of the meeting or so and I hope we dont let this happen again or the new dev meetings will get very uninteresting. Please next time try to avoid arguing about stupid topics like this while we are trying to give basic info to new devs. I think topics like this just need better WIKI Docs and not discussion with new devs. (Or limit to 5min intro) Hi Nathan, I didnt mean to say scons does full rebuilds, just that its slower if you do quick rebuilds. SCons is great to get a build running however for development Im now quite convinced its not the way to go. When nothing needs building, CMake's Makefiles take around 2.1 seconds on my system. Scons takes between 30 and 40 seconds. Time to compile and link with one change with CMake made is 6.8 second or so. I have tried optimizing scons before and I can get moderate speedups... but it still doesnt get close to CMake's. SCons with BF_QUICK gives more acceptable times but this means I waste time thinking about what libs to build and occasionally getting it wrong and having to find out why BF_QUICK failed. I appreciate your work on scons and dont mean to belittle it but with CMake so much faster for rebuilds I feel justified in recommending CMake over scons for people who intend to build often. - Campbell On Thu, Jan 7, 2010 at 8:46 AM, Nathan Letwory jesterk...@letwory.net wrote: Roger Wickes wrote: We held our second monthly new developer meeting( http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings) on Sunday, attracting x new developers to the Blender family. Minutes are here: http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda/NewDev_meetings/2010-01-03rd . We discussed Build systems, Patch Submission, and Python, with a focus on Cmake versus Scons. Hi, great to see that the second new dev meeting has been held - too bad I couldn't be there, since SCons has been talked about, too. I feel I have to make a small comment though: SCons never does a full recompile, when it is not necessary (and it hardly ever is). So in that sense, SCons will also do incremental builds. Sure, it does read in the SConscripts, but *that is not equivalent to a complete rebuild*. It does pose some slight overhead when starting a build, but that should not be the reason to start favoring CMake over SCons. Again: SCons builds only what is needed. When doing a clean rebuild, (remove *everything* created by SCons/CMake before doing your build), I assure you that you won't find useful differences in build times. I have started writing out docs on the SCons system on my blog http://www.letworyinteractive.com/b/building-blender-with-scons/ (see also the top navigation for more links). More info there will gradually be published as I get it all written out. It already contains good info on how the configuration of the system goes. /Nathan ___ 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] New Developer Meeting minutes
2. the include path for quicktime_export.h is wrong in the generated
projectfiles. I tried to fix this but after experimenting with the
CMakeList files for an hour just decided to wait for someone more
familiar with the cmake files.
- Andrea
The fix for this problem :
Index: source/blender/makesrna/intern/CMakeLists.txt
===
--- source/blender/makesrna/intern/CMakeLists.txt(revision 25815)
+++ source/blender/makesrna/intern/CMakeLists.txt(working copy)
@@ -63,7 +63,7 @@
ENDIF(WITH_DDS)
IF(WITH_QUICKTIME)
-SET(INC ${INC} ../../quicktime)
+SET(INC ${INC} ../../quicktime)
ADD_DEFINITIONS(-DWITH_QUICKTIME)
ENDIF(WITH_QUICKTIME)
Blender compile with quicktime on msvc express 2008. Quicktime is not
installed on my computeer I can't test the export.
Regards
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting minutes
Since this thread is now about build systems, can we please change the subject line? Ken Campbell Barton wrote: Not sure what dependency updates are exactly - if files are added you need to run cmake . in the build dir but aside from that I never had any dep propblems. I'm tempted to install Windows just to get rid of the MSVC Project files and have CMake create propper debug builds... it cant be that hard can it? @Martin, my experience with using scons and eclipse isnt so good, it works OK but a bit annoying to setup, I recall I needed to have eclipse call a shell script that called scons. Eclipse + Cmake is nicer, and takes the work out of setting up the project each time. especially if you want to switch to developing in branches for a bit. On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier the...@yahoo.com wrote: --- On Thu, 1/7/10, Erwin Coumans erwin.coum...@gmail.com wrote: New developers (and myself) can browse and debug code much easier in an IDE such as msvc, Xcode or K develop, in my opinion. And manual updating projectfiles is a waste of time. It's very easy to use Eclipse (with CDT) with scons. K Develop was pretty easy to setup too the last time I tried. There was no project files to update or anything. 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@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] New Developer Meeting minutes
By the way, if OpenCollada breaks the cmake build system, it should be disabled I think. Hopefully that motivates someone who needs OpenCollada to fix it. Can someone disable OpenCollada by default it in cmake? Thanks, Erwin 2010/1/7 Ken Hughes khug...@pacific.edu Since this thread is now about build systems, can we please change the subject line? Ken Campbell Barton wrote: Not sure what dependency updates are exactly - if files are added you need to run cmake . in the build dir but aside from that I never had any dep propblems. I'm tempted to install Windows just to get rid of the MSVC Project files and have CMake create propper debug builds... it cant be that hard can it? @Martin, my experience with using scons and eclipse isnt so good, it works OK but a bit annoying to setup, I recall I needed to have eclipse call a shell script that called scons. Eclipse + Cmake is nicer, and takes the work out of setting up the project each time. especially if you want to switch to developing in branches for a bit. On Thu, Jan 7, 2010 at 3:52 PM, Martin Poirier the...@yahoo.com wrote: --- On Thu, 1/7/10, Erwin Coumans erwin.coum...@gmail.com wrote: New developers (and myself) can browse and debug code much easier in an IDE such as msvc, Xcode or K develop, in my opinion. And manual updating projectfiles is a waste of time. It's very easy to use Eclipse (with CDT) with scons. K Develop was pretty easy to setup too the last time I tried. There was no project files to update or anything. 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@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
Re: [Bf-committers] New Developer Meeting Minutes
Dev QA session would be Jan 3 (5 days from now). Im ok to be in 1hr before the meeting to answer questions. Anything we need to arrange/announce... etc? (Anyone know how to use Blender nations new self publishing system?) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] New Developer Meeting Minutes
Hi Campbell, --- On Mon, 12/7/09, Campbell Barton wrote: Can this be a further summarized? I've wikified the very cool RNA/Operators lessons you, theeth and dingto made at the NewDev meeting, see http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/RNA and http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/Operators Also, after the regular Sunday meeting theeth took the time to patiently list most of the Blender's code folders with a bit of introduction for each one of them, see http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/Files_structure While I was doing this stuff I've prepared a summary, which you can find pasted below. I'd like to thank again mentors for this NewDev Meeting, it has been very informative and cool :) Cheers, Luca === NEW DEV MEETING 2009-12-06th Mentors: ideasman42, theeth and DingTo Log: http://blenderartists.org/~theeth/bf/meeting-newdev-09-12-06.txt Agenda has been: 1. Decide if talk about 2.49 codebase or 2.5 only 2. Talking about C codebase or Python? 3. Mentorships 4. New devs interests? 5. Source code comments and documentation 6. General questions 6.1 Blender architecture and how to grasp the big picture 6.2 Finding things in the code 6.3 RNA explanation 6.4 Operators explanation 1. Decide if talk about 2.49 codebase or 2.5 only - We agreed not talking 2.4x code. 2. Talking about C codebase or Python? - majority wanted C, some C/python, - ideasman42 and theeth agreed that: - C/Python is very vague and it depends very much on where developers are interested in working, what problems they try to solve - also, in 2.5, it's not as clear cut as it used to be - ideasman42 asked if newdevs are more o C or python: - most are python/C or python with some basic C - one said to be C/C++ 3. Mentorships - PapaSmurf asked whether experienced developers would like to mentor a new developer, like we did with GSOC: theeth showed interest :) 4. New devs interests? - kattkieru: armature and constraints systems, Python import/expoorter - amennelet would like to work on windows manager - djaddison: low level event handling - dmbasso/yoff: physics simulation, specifically muscle simulation - Campbell answered this is too spesific area . - nfz: interested in 2.5 todo list and bug squashing - Interesting note: KAHR-Alpha isn't bullet C++? ideasman42 yes, but it has a C api. Not sure how effective that is though, only used the C++ api 5. Source code comments and documentation - matd would like to see important souce code files commented at the beginning, in order to see what's a certain file for. - PapaSmurf and matd would liek to have _readme in each folder explaining the purpose fo the contents of that folder (at least in the root dir of all important modules like wm, rna, etc ...) 6. General questions 6.1 BLENDER CODE ARCHITECTURE: THE BIG PICTURE - http://www.blender.org/development/architecture/ - http://www.blender.org/community/get-involved/ - (!!) theeth has patiently explained most of the folders in the code: http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/Files_structure - Ideasman42 suggestion: Not sure this is GOOD advice, but I found its good not even to try understand the big picture, just learn one area well. Theeth agrees. - DingTo started with UI scripts, expanded to RNA and Nodes, nfz too. - General agreement about starting from UI scripts or operators (in files ending in _ops.c). 6.2 FINDING THINGS IN CODE - Campbell asks how people searches in the code - cscope (kh_pylon) - code::blocks (nfz) - kscope, crep, http://wiki.blender.org/index.php/User:Ideasman42#crep (mindrones) 6.3 RNA EXPLANATION (http://wiki.blender.org/index.php/Dev:Doc/Blender_Source/RNA) RNA is a data access and simple operations API. It sits on top of the low level C structs (called DNA). It's very basic stuff, like links between different structures, specific types and range of different members, ... From that, we generate the RNA Python API RNA defines not only the name of the property, also it sends an Notifier to tell Blender what has changed, and it contains the UI Text and Tooltip When you change that you also want blender to redraw for instance, or update its childrens location (childrens matrix) We dont want to define these update calls for anim/ui/py - so instead each access via rna: ob.location in python does an rna lookup, gets the array in C, the python api converts this known rna type to a vector and returns the value. Internally it does py - coerce into an array - rna array set function - DNA array. Probably this is only interesying to py api devs. It might be interesting to note that RNA definition is split in
