[Bf-committers] Questions about SCons

[Kent Mein]

In reply to Tron Thomas (tron.thomas at verizon.net):

>From the scons documentation you want to call scons with:
BF_DEBUG=1

This will build a fully debuging version of blender, there are ways
to only build selected parts of blender with debugging support also.
look at doc/blender-scons.txt specifically the sections about:
BF_QUICKDEBUG and BF_DEBULG_LIBS

It's a compilicated system to figure out what needs to be recompiled
at a specific time.  Usually the build systems do a pretty good job on
the simple stuff, but it will probably never be foolproof.

If you have any suggestions for improving things let us know.

Kent

> I have been trying to using SCons to create a debug build of Blender  
> on Mac OS X, and I have some questions I'm hoping I can get some  
> answers to.
> 
> In general SCons works great for building.  All someone needs to do  
> is type a cammand and then wait for the build to complete.  Compared  
> to what I've had to go through to get Blender to build using GNU  
> make, this clearly a much simpler and easier approach.
> 
> For as nice as this is there are some problems, and I'm wondering how  
> well these problems are understood and what action is being taken to  
> corect them.
> 
> For example, modifying a single file requires a build from the root  
> of the source.  This means that SCons has to check every build target  
> to make sure its up to date.  This make rebuilding for a simple code  
> change slow.
> 
> Even worse is the fact SCons does not realize that targets need to be  
> rebuilt when source files are modified.  I found that the object  
> files resulting from the compliation of the changed source files must  
> be manually deleted for SCons to realize the files to be re-compiled.
> 
> What can someone do to avoid these types issues when building with  
> SCons?
> 
> Even more important, are the difficulties of trying to create a  
> debuggable program in the first place.  The build output doesn't say  
> much about what options are being applied to compiled and linked  
> files.  Its hard to know things like whether the final result will  
> contain debug information or not.  Also knowing what it takes to  
> change the build options is not obvious.
> 
> The documentation on the Internet for changing build options says  
> that the first time scons is started, the file config.opts is  
> generated.  To my knowledge, this is not correct.  The config.opts  
> file is never created.  Creating a config.opts file and adding  
> options to it also has no affect on the build results.
> 
> Paying attention to the build output and some investigation of the  
> main SConstruct script revealed that the actual way to modify build  
> settings is to create a file named user-config.py in the same  
> directory as that main SConstruct script.  Adding entries like the  
> following to this user-config.py file can produce a debug build:
> 
> CCFLAGS.extend(['-g', '-O0'])
> CXXFLAGS.extend(['-g', '-O0'])
> 
> Even after doing this, all was not right.  Debugging the code  
> indicated that despite the fact that the user-config.py file  
> specified no optimization should be applied, the code does in fact  
> contain optimizations.  Debugging optimized code can be tricky and  
> confusing.
> 
> So far I have been unable to find where these optimization options  
> are applied and how to eliminate them.
> 
> How can someone use SCons to create a debug build of Blender that  
> does not contain any optimizations?
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers

-- 
mein at cs.umn.edu
http://www.cs.umn.edu/~mein