Hey Graeme, SCons is awesome! (Bias note: I've been one of the developers since shortly after the project went public. But that's because I immediately saw how much better a build tool using Python syntax is than make. Or pretty much anything, really.) I use it to build every project I start, especially the larger ones. The focus on build reliability and one global dependency tree is great. You almost never have to do an scons -c and scons in order to get a correct build. And when you do have to clean in order to verify it's correct, something is buggy. :) Another advantage of SCons is Steven Knight, the guy who originally created it. He's an incredibly awesome manager and a nice guy all around. If you feel good about SCons, he does too. If you don't feel good, he and the rest of the community try to make SCons a little nicer. The SConstruct I attached is a total hackjob so I could get something compiling as fast as possible. A better one might look like: def python_tool(env): pybase = 'python%s' % sys.version[0:3] env.Append(CPPPATH=[os.path.join(sys.prefix, 'include', pybase)], LIBPATH=[os.path.join(sys.prefix, 'lib', pybase, 'config')], LIBS=['lib%s' % pybase]) if env['PLATFORM'] not in ['cygwin', 'win32']: env.Append(LIBS=['util']) def boost_python_tool(env): env.Append(CPPDEFINES=['BOOST_PYTHON_STATIC_LIB', 'BOOST_PYTHON_STATIC_MODULE'], CPPPATH=['$boostIncludes'], # boostIncludes is a PathOption LIBS=['boost_python-gcc']) import os env = Environment(ENV=os.environ, tools=['default', python_tool, boost_python_tool]) env.SharedLibrary('hello', 'hello.cpp') Then you could start to migrate in options (via the Options object) and platform tests (via testing env['PLATFORM'] and such. On this list, I keep hearing this vibe "you should use bjam to make sure you get the voodoo build commands right, otherwise things will fail in unpredictable ways." I've never had a problem (win32, cygwin, linux), though. I just define BOOST_PYTHON_STATIC_LIB, BOOST_PYTHON_STATIC_MODULE (for embedding), and BOOST_PYTHON_NO_TEMPLATE_EXPORT (although this is kinda broken in 1.31). Use SharedLibrary if you're building an extension module, etc. Chad On Fri, 2 Jul 2004 12:21:07 -0700, Graeme Lufkin <graeme.lufkin@gmail.com> wrote:
I'm interested to see you're using SCons to build your modules. Would you mind posting a short account of your experience using SCons, both in general and with Boost.Python? I still wrestle with Makefile vs Boost.Build vs tearing-my-hair-out every once in while. A more complicate SConstruct file would be great to look at too. Thanks
On Fri, 2 Jul 2004 11:48:43 -0500, Chad Austin <caustin@gmail.com> wrote:
Chad@basilisk ~/tmp/bp $ scons scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... g++ -DBOOST_PYTHON_STATIC_LIB -DBOOST_PYTHON_NO_TEMPLATE_EXPORT -I/usr/local/inc lude/boost-1_31 -I/usr/include/python2.3 -c -o hello.os hello.cpp g++ -shared -o hello.dll hello.os -L/usr/lib/python2.3/config -L/usr/local/lib - lboost_python-gcc -lpython2.3 scons: done building targets.
-- -- Graeme graeme.lufkin@gmail.com
_______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
-- Chad Austin http://aegisknight.org/