[Bf-committers] New Developer Meeting minutes

Xavier Thomas xavier.thomas.1980 at gmail.com
Thu Jan 7 18:05:18 CET 2010


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).


2010/1/7 Campbell Barton <ideasman42 at 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 <jesterking at 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 at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list