I just started learning to use SCons, anticipating that it solves some of my issues with make. I'm creating a source hierarchy to understand the basics of SCons.
Let's start with this folder structure:
- test/foo: contains main.cpp, main.h
- test/bar: contains its own main.cpp, main.h
- test/common: contains utils.cpp and utils.h used by both foo and bar
- test/external/moo: the source to some external library, containing 'configure' which produces 'Makefile' (not using SCons), so SCons needs to invoke 'make' after 'configure'; I suspect this part might be tricky when build dirs are used
- test/build/debug: build dir for debug
- test/build/release: build dir for release
Esto es lo que me gustaría hacer:
Have two types of builds: debug/release where the only difference is that debug specifies -DDEBUG to g++
Use build dirs so that no .o files are created in my source tree. Let's call these build dirs "build/debug" and "build/release"
Be able to invoke ./configure and make on another project that does not use SCons, followed by linking libmoo.a it produces with my project
Have the builds be perfectly parallel (scons -j9 for an 8-core?)
Have some debug/release-independent way of specifying libraries to link. Something like:
env.Program(target='foo', source=['foo/main.cpp', '#build/(DEBUG_OR_RELEASE)/lib/libsomething.a'])
What would the very basic SConstruct/SConscript files to do the above look like? Even just pointers in the right directions would be great too!
Gracias por adelantado :-)
preguntado el 27 de agosto de 11 a las 18:08
I do this for builds for multiple platforms (rather than debug/release) but the concept's the same. The basic idea is that you need 2 files in the project root - a SConstruct to set up the build directories (or "variant directories" as they are known in scons), then a SConscript that describes the actual build steps.
In the SConstruct file you'd specify the variant directory and its corresponding source directory:
SConscript(dirs='.', variant_dir=variant_dir, duplicate=False, exports="env")
Now you want variant_dir to depend on a flag. You'd use AddOption or Variables to do this. Here's one example of a complete top-level SConstruct to do that:
# build with `scons --debug-build` for debug. AddOption( '--debug-build', action='store_true', help='debug build', default=False) env = Environment() if GetOption('debug_build'): env.ParseFlags('-DDEBUG') variant_dir = 'build/debug' else: variant_dir = 'build/release' SConscript(dirs='.', variant_dir=variant_dir, duplicate=False, exports="env")
AddOption is easiest to use, but if you use Variables then you can cache the result between runs, rather than having to spell out "scons --debug-build" each time.
All the directory setup and associated cruft is in the SConstruct. Now the SConscript file is quite simple and doesn't need to worry about build directories at all.
Import('env') env.Program(target='foo_prog', source=['foo/main.cpp', 'lib/libmoo.a']) # foo_prog since foo already exists as the name of the directory...
This is about the simplest way I've found to set up different build directories without getting weird errors. It's also pretty flexible - you can add different platform builds just by modifying the "env" in the top-level script without having to alter the actual meat of the build.
The only spanner in the works in your question is the way to compile autoconf-style projects directly from SCons. The easiest way is probably with a couple of Command() calls, but SCons likes to know about the inputs and outputs of each step, so this can get hacky. Also, you have to rely on the autoconf build having a correct VPATH setup - some projects don't work if you try and compile outside the source tree. Anyway, a way to compile autoconf projects would be something like this:
import os Import('env') # get the path to the configure script from the "moo" source directory conf = env.File('moo/configure').srcnode().abspath # Create the "moo" build directory in the build dir build_dir = env.Dir('.').path moo_dir = os.path.join(build_dir, 'moo') Mkdir(moo_dir) # run configure from within the moo dir env.Command('moo/Makefile', 'moo/Makefile.am', conf, chdir=moo_dir) # run make in the moo dir env.Command('moo/libmoo.a', 'moo/Makefile', 'make', chdir=moo_dir) env.Program(target='foo_prog', source=['foo/main.cpp', 'moo/libmoo.a'])
Running the configure step from the source directory while the current working directory is somewhere in the build hierarchy is awkward. The make step is less messy, but still needs to know about the current build directory. Since you specify "libmoo.a" as an output of the make step and libmoo.a as an input to the program, all the dependencies Just Work, so a parallel build works fine. Parallel builds only break down when you fudge dependencies too much.
I know this is an old question, I just want to add an alternative to:
- be able to know the current variant in the sconscript file (not only in the parent)
- and to be able to build multiple variants in a single scons command
sconstruct file (the parent), we define a
variants with the list of the variants that we allow (eg.
Then to be able to know the current variant in the
sconscript file, we just loop option we have defined and export it into the
genv as variable name to notate ambiente global:
# sconstruct opts = Variables() opts.AddVariables( ListVariable('variants', 'list of variants to build', 'all', names = ['debug','release']), ) genv = Environment( options = opts ) for variant in genv['variants']: SConscript('sconscript', exports=['genv', 'variant'], variant_dir='#build/'+variant, duplicate=False)
sconscript file we
genv and we can use the
variant variable to do our setup in the local environment
# sconscript Import('*') import os.path env = genv.Clone() if variant == 'debug': env.Append( CPPFLAGS = ['/Zi']) src = 'src/hello.cpp' app,ext = os.path.splitext(os.path.basename(src)) obj = env.Object ('obj/'+app, src) bin = env.Program('bin/'+app, obj)
El uso de un
ListVariable allows us to call
This last command (and the default command) builds all the variants.
There's a good solution to define multiple build modes ('debug', 'release') in the SCons Wiki:
That's how the richq SConstruct file would look like:
#get the mode flag from the command line #default to 'release' if the user didn't specify mymode = ARGUMENTS.get('mode', 'release') #check if the user has been naughty: only 'debug' or 'release' allowed if not (mymode in ['debug', 'release']): print "Error: expected 'debug' or 'release', found: " + mymode Exit(1) #tell the user what we're doing print '**** Compiling in ' + mymode + ' mode...' env = Environment() if mode == 'debug': env.Append(CPPDEFINES = ['DEBUG']) variant_dir = 'build/debug' else: variant_dir = 'build/release' SConscript(dirs = '.', variant_dir = variant_dir, duplicate = False, exports = "env")
scons mode=release (o solo
scons as the release is the default mode), or