Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 09 Apr 2006 23:16:54 -0700
From:      Alexander Botero-Lowry <alex@foxybanana.com>
To:        freebsd-ports@freebsd.org
Subject:   Ports using SCons
Message-ID:  <200604100616.k3A6Gu2S051131@Laptop.mine.box>

next in thread | raw e-mail | index | archive | help
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

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604100616.k3A6Gu2S051131>