Ports Using SCons

Alexander Botero-Lowry alex at foxybanana.com
Fri Apr 14 08:51:30 UTC 2006

I've been working some more on bsd.scons.mk (updates have been pushed to 

I've added better support for CXXFLAGS, as well as used 

The other thing is I've added support for a variable, ${SCONS_BUILDENV}, 
anything set in this variable has ${SETENV} run on it. The reason for 
this is that sometimes hackish scons scripts will use os.env (the python 
magic for getting the system envionrment variables) to pick up some 
stuff, and not read it at all from the scons enviornment. XMMS2's java 
bindings have the misfortune of doing this to get JAVA_HOME. So 
${SCONS_BUILDENV} provides a way to set enviornmental variables that 
might be used by a port.



I've been working on a common makefile for ports that use scons. SCons is basically a build system written in python that does 
things kind of strangely by the standards of how we're used to dealing with makefiles. With that in mind it's a good idea to 
look at some of the problems that ports using SCons have run into in the current situation (ie, where each port maintainer must 
basically implement their own SCons interface in the ports makefile).

lang/tolua++ is an excellent example of a port that has some scons related issues. (I've commented out NO_BUILD to faciliate 
these demonstrations):

Laptop# make CFLAGS=-O3
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/bin/tolua.o -c -O2 -ansi -Wall -I/usr/local/include -Iinclude src/bin/tolua.c
gcc -o src/bin/toluabind.o -c -O2 -ansi -Wall -I/usr/local/include -Iinclude src/bin/toluabind.c

Where'd my CFLAGS go? Well scons doesn't even use that as its variable name, it uses CCFLAGS, so ok, let's define CCFLAGS:

Laptop# make CCFLAGS=-O3
===>  Building for tolua++-1.0.4
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/bin/toluabind.o -c -O2 -ansi -Wall -I/usr/local/include -Iinclude src/bin/toluabind.c

Nope. That's because you have to explicitly pass CCFLAGS to scons. SCons doesn't use the system enviornment for its enviornment, 
it has an enviornment of its own, and the variables in that enviornment have to be passed like this:


Ok. So, not every scons port has this problem, BUT when you look at some of the solutions that people have used to solve this 
problem you begin to realize that this just isn't the way it should be done.

games/marsnomercy honors my CFLAGS! But why does it do this? The SConstruct (Makefile in the SCons world) has been patched:

+        env.Replace(CC = os.environ['CC'])
+        env.Replace(CXX = os.environ['CXX'])
+        env.Replace(CXXFLAGS = os.environ['CXXFLAGS'] + ' `' + SDL_CONFIG + ' -

Seems kind of silly to be patching the SConstruct when you can just do: scons CXXFLAGS="${CXXFLAGS}"... But either of those two 
solutions work.

Ok, so there are two solutions, both of which are quite the fulhack. An example of an scons port doing it by passing the correct
 variables to scons is my own port audio/xmms2:

        cd ${WRKSRC} && \
                ${SETENV} JAVA_HOME=${JAVA_HOME} scons CC=${CC} LINKFLAGS="${LDF
                LIBPATH=${LOCALBASE}/lib CPPPATH=${LOCALBASE}/include \
                PKGCONFIGDIR=${PREFIX}/libdata/pkgconfig EXCLUDE="${EXCLUDE}" \
                PREFIX="${PREFIX}" ${SCONS_TARGET}

That's just nasty, and that's what it takes for any SCons port to do it what I consider the Right Way. (Patching any file is a 
bad idea if you can do it without patching).

With this background in mind I offer a third solution: my common makefile.

You can look at the work so far at: http://www.reed.edu/~boterola/bsd.scons.mk <http://www.reed.edu/%7Eboterola/bsd.scons.mk>

This does work, today, right now. I have a rewrite of the lang/tolua++ port using it. I started with lang/tolua++ because 
it was a very simple port, and because the developers had not done much to modify default scons. xmms2, which I will convert 
to the common makefile soon is a lot more complex, and upstream has made a lot of project specific additions and changes (which 
are all very nice and I am happy we implemented), which I will be able to easily deal with thanks to the SCONS_ARGS variable :) 

I don't want to start a major bikeshed or flame war, but I would really like any feedback and insight people have to offer on 
this subject. 

Also, to any of the maintainers of the ports I singled out, please don't take offense, I think the way I do it in audio/xmms2
 is kind of crap too, that's why I'm trying to make a nice unified solution to the problem.

Alexander Botero-Lowry

ps.. Off list, please cc me.

More information about the freebsd-ports mailing list