[Bf-committers] Proposal: New build system for blender (+ topic for meeting)

Michel Selten bf-committers@blender.org
Sat, 13 Dec 2003 14:38:03 +0100


The last couple of months I've been trying to get the autoconf system
working better. My aim was to get it to actually get it working on
Windows using Cygwin. I stopped when I ran into a very big usability
problem. The configure.ac script is required to be in UNIX format; ie.
no DOS cr/lf characters. I believe we cannot force developers to use
specific text editors only for editing the files in the build
So, that was the moment for me to say to myself: "Autoconf is not the
way to go for multiplatform development." (I hear a couple of you say:
"I told you so!" :) )
Still, I think the current Makefiles are a bit lacking in some areas,
for example dependency generation. Of course, with a lot of effort, this
can be resolved.
Since Blender depends on Python for the API, we can also use Python for
building Blender; every developer is required to have Python installed
on his system anyway.
After a search on the internet, I found SCons. Looking through the
documentation and features, I thought this could be the system for
building Blender.

The last 2 weeks, I've been spending my time to get blender to build
with SCons. The bulk of the effort was done in 2 days, but I ran in a
problem - which ultimately appeared to be a bug in SCons and me using
SCons not the way I should :blush:

What I've done is to get the build to work only on my system - as a
quick test. Configurations and such can be done afterwards (now).

Just like the autoconf system, each directory has a file specifying
which files to compile and what the target is. The main starting point
for a SCons build system is the SConstruct file - which resides in the
root of the source tree.
There I've specified which libraries I need for final linking, compiler
flags and include paths. A couple of these parameters should be put in a
user configurable options file. So, similar to the current Makefiles,
the developer has to specify where to find the libraries, what libraries
to link and where the include paths should point to.
But, since the SConstruct file and all directory specific SConscript
files are in essence Python scripts, we can make it intelligent enough
to go searching for the needed tools, libraries and header files.

Some very interesting features:
- Dependency checking using MD5 checksums by default. No checking for
  time/date changed files by default - can be done with a commandline 
- Comparable build times with autoconf system.
  I compared the autoconf system with the Scons system. Both not 
  building the game engine - that's why I couldn't compare to the
  clean build autoconf+./configure:		3:30
     (running ./configure took 0:43)
  clean build Scons:				2:33
- User option file for specifying which components to build
  (international, gameengine, openal, ...). This I have not implemented
- Can generate Visual C++ 6 .dsw and .dsp files. (Not tested)
- Very helpful scons developers on the mailing lists. I got a helpful 
  response within 1 hour.
- Links of interest: www.scons.org. A couple of useful FAQ questions
  there as well!

My proposal would be to use SCons as the default build environment for
Blender 2.5 - if Blender 2.5 is still the plan. If not:
I would propose to implement SCons in current bf-blender and remove the 
autoconf system. (For Linux users (me too), we could include a very tiny
configure.ac script that checks for scons and generates a makefile which
calls SCons).
If the feature to generate VC 6 files indeed works, we should also
remove that build system from cvs. With each added/removed .c file,
there's always too much time needed for getting the build systems to all
work again.

Okay, this seems like a nice topic for the meeting tomorrow.

With regards,