Re: [Bf-committers] Old patches in tracker deleted?
2010/1/10 Tom M letter...@gmail.com: Kier, However, the patch at the URL above is gone. I have long since lost the computer that had that patch, expecting that it would live on in the tracker. Is it still around somewhere? ask jesterKing I think he has copies of everything for the migration to a new tracker, I *might* have. Depends if the file existed during creation fo the copy :) I'll look for it at some point. /Nathan ___ 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
