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
http://www.reed.edu/~boterola/bsd.scons.mk.
I've added better support for CXXFLAGS, as well as used
${INSTALL_TARGET} for the default SCONS_INSTALL_TARGET.
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.
Alex
Hi!
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:
scons CCFLAGS="${CFLAGS}"
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 + ' -
-cflags`')
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:
do-build:
cd ${WRKSRC} && \
${SETENV} JAVA_HOME=${JAVA_HOME} scons CC=${CC} LINKFLAGS="${LDF
LAGS}" CCFLAGS="${CFLAGS}" \
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.
Thanks,
Alexander Botero-Lowry
ps.. Off list, please cc me.
More information about the freebsd-ports
mailing list