I try to setup a build system to build a shared lib MySharedLib and a binary MyBinary that rely on MySharedLib. The build system should be able to install MySharedLib and MyBinary when asked for it, and only when asked for it.
import os.path
env = Environment()
env.Append(CCFLAGS='-g -Wall -ansi -O2')
prefix = '/usr/local'
lib_dir = os.path.join(prefix, 'lib')
bin_dir = os.path.join(prefix, 'bin')
Export('env prefix lib_dir bin_dir')
libMySharedLib = SConscript('libMySharedLib/SConscript')
MyBinary = SConscript('MyBinary/SConscript')
env.Alias('install', env.Install(lib_dir, libMySharedLib))
env.Alias('install', env.Install(bin_dir, MyBinary))
When I run SCons with no command line arguments, MySharedLib and MyBinary are built, but it also it try to install them. I want them installed only just when I ask for the install target. I tried many times, read the docs, but I can't figure it out.
By default, and when no target are set into the scons script, scons builds every target in '.'. You can control which targets to build by default with the Default function:
lib = SConscript('libMySharedLib/SConscript')
bin = SConscript('MyBinary/SConscript')
env.Alias('install', env.Install(lib_dir, lib))
env.Alias('install', env.Install(bin_dir, bin))
# By default (scons called with no explicit target), only build bin
Default(bin)
AFAIK, there is no way to tell scons to build nothing, although you could create a dummy target I suppose.
Related
I need to do purify build using SCons. Normally in nmake we would do
Nmake install -purify_7.0.1.0-008
How to do the same in SCons? Do I need to add any change in SConstruct file?
You'll need to prefix SHCC,CC, SHCXX, CXX, SHLINK, LINK with purify, and likely add the path to your purify binary to env['ENV']['PATH']
You'll need to do this anywhere (in the main SConstruct, all SConscripts, and if you have any code in site_scons) which creates an Environment() to use.
If you create one Enviroment() and that gets exported to your SConscripts where it's then env.Clone()'d, then you'd only have to change it in the initial env=Environment()
Here's an example (not tested):
env=Environment() # this is your existing code
for v in ['SHCC','CC','SHCXX','CXX','LINK','SHLINK']:
orig_value = env.subst('$%s'%v)
env['v'] = "purify "+ orig_value
print("Changing $%s from :\n%s\nto:\n%s",v, orig_value, env['v'])
I have defined two libraries - one static, one shared - to be built in a "libraries" subdirectory with an SConscript file. This SConscript is then invoked from SConstruct in the parent directory, which dilligently builds both libraries.
D:\tony\libraries\SConscript:
# Define environmental/project constants
CPPPATH = ['../headers']
SOURCES = ['greeter.cxx']
# Inherit the parent environment and update values if necessary.
Import('env')
# Build targets using defined environment variables.
print "Building libraries"
env.StaticLibrary(target = 'lib_greeter.a', source = SOURCES, CPPPATH = CPPPATH)
env.SharedLibrary(target = 'greeter.dll', source = SOURCES, CPPPATH = CPPPATH)
D:\tony\SConstruct:
# Define environmental/project constants
TOOLS = ['gcc', 'g++', 'gnulink', 'ar']
PATH = ['C:/cygwin/bin']
CYGWIN = ['nodosfilewarning']
DECIDER = 'MD5-timestamp' # Use a combination of timestamps and checksums to decide if dependencies have changed.
# Initialize the Default Environment and update values.
env = DefaultEnvironment(tools=TOOLS)
env['ENV']['PATH'] = PATH
env['ENV']['CYGWIN'] = CYGWIN
env.Decider(DECIDER)
# Call subsidiary SConscript files with defined environment variables.
SConscript('libraries/SConscript', exports = 'env', duplicate = 0) # do not copy src files to build directory.
But how can I specify that I only wish to build one of the libraries (eg. greeter.dll) when invoking scons on the cmd line?
I had previously defined some custom command line options using AddOption to introduce some flow control, but somehow that didn't feel quite right.
Your question can be read one of two ways:
How can I select the target to build by naming it on the command line.
How can I arrange things such that greeter.dll is built by default if no target is named on the command line.
If your question is about the first case, you can just name the path to the generated file when you invoke SCons. Given your files, I would expect that to look something like scons libraries\greeter.dll.
If you are asking about the second case, you can use env.Default("greeter.dll") in your SConscript, and then when you invoke SCons with no arguments it will be built automatically.
I have a simple SConstruct file that contains the following:
env = Environment()
env.ParseConfig('sdl2-config --cflags')
When I run it, I get the following error:
$scons
scons: Reading SConscript files ...
/bin/sh: sdl2-config: command not found
However, I can run sdl2-config from the same shell:
$ sdl2-config --cflags
-I/opt/local/include/SDL2 -D_THREAD_SAFE
$ which sdl2-config
/opt/local/bin/sdl2-config
Is there something special I need to do to make scons use my PATH?
I'm on MacOS 10.9.5, using scons 2.3.4 installed by MacPorts.
Yes. SCons does not use the user's path by default. You need to pass the PATH explicitly to the Environment:
import os
env = Environment(ENV = {'PATH' : os.environ['PATH']})
See the SCons FAQ.
I am using scons to compile with vc10 and renesas compiler.
Is there any commands to get an executable in debug mode?
If I executed my project with the command "scons and enter" it is going to release mode.
I am unable to debug that .exe file using the visual studio debugger.
Can anyone tell me how to get the debugging executable in debug mode?
Is there any commands or flags to set in scons?
To get the executable in debug mode, its just a simple matter of adding the appropriate compiler debug flags to the CXXFLAGS construction variable, as follows:
env = Environment()
env.Append(CXXFLAGS = ['/DEBUG'])
But this is rather basic, and I imagine you would want to be able to control when the executable is compiled in debug mode via the command line. This can be done with command line targets or command line options (like debug=1)
To use targets, you could do something like this:
envRelease = Environment()
envDebug = Environment()
envDebug.Append(CXXFLAGS = ['/DEBUG'])
targetRelease = envRelease.Program(target = 'helloWorld', source = 'helloWorld.cc')
# This makes the release target the default
envRelease.Default(targetRelease)
targetDebug = envDebug.Program(target = 'helloWorldDebug', source = 'helloWorld.cc')
envDebug.Alias('debug', targetDebug)
If you execute SCons with no command line targets, then the release version will be built, as specified by the envRelease.Default() function. If you execute SCons with a debug target, like this: scons debug then the debug version will be built as specified by the envDebug.Alias() function.
Another way to do this is with command-line arguments, like this: scons debug=0 or scons debug=1, which would allow you to perform some logic in your build scripts, thus allowing you to more easily control the variant-dir, etc, as follows:
env = Environment()
# You can use the ARGUMENTS SCons map
debug = ARGUMENTS.get('debug', 0)
if int(debug):
env.Append(CXXFLAGS = ['/DEBUG'])
env.VariantDir(...)
else:
env.VariantDir(...)
env.Program(target = 'helloWorld', source = 'helloWorld.cc')
Look here for more command line handling options.
And one final option, that I prefer is to just always build both versions, each in their respective variantDir (build/vc10/release and build/vc10/debug for instance).
envRelease = Environment()
envDebug = Environment()
envDebug.Append(CXXFLAGS = ['/DEBUG'])
envRelease.VariantDir(...)
targetRelease = envRelease.Program(target = 'helloWorld', source = 'helloWorld.cc')
# This makes the release target the default
envRelease.Default(targetRelease)
# This allows you to only build the release version: scons release
envRelease.Alias('release')
envDebug.VariantDir(...)
targetDebug = envDebug.Program(target = 'helloWorld', source = 'helloWorld.cc')
# This makes the debug target get built by default in addition to the release target
envDebug.Default(targetDebug)
# This allows you to only build the debug version: scons debug
envDebug.Alias('debug')
For MSVC you need to add the debug flag to the linker (LINKFLAGS). An example...
Program(path, CPPPATH=env['CPPPATH'], CCFLAGS=env['CCFLAGS'], LIBS=['lib'],
LIBPATH='.', LINKFLAGS=['/DEBUG'])
You may also need to add the flags /Zi and /EHsc to the compiler as well
# this line is meant to go before calling Program
env.Append(CXXFLAGS = ['/Zi', '/EHsc', '/DEBUG'])
obviously in an ideal scenario you would add the arguments logic to detect when you need them seen in the accepted answer.
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
Here's what I'd like to do:
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!
Thanks in advance :-)
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
In the sconstruct file (the parent), we define a ListVariable named variants with the list of the variants that we allow (eg. ['release', 'debug']).
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 sconscript.
I use genv as variable name to notate global environment:
# 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)
In the sconscript file we Clone de genv and we can use the variant variable to do our setup in the local environment env:
# 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)
Using a ListVariable allows us to call
scons variants=release
or
scons variants=debug
or
scons variants=all
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:
http://www.scons.org/wiki/SconstructMultiple
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")
You then call scons mode=release (or just scons as the release is the default mode), or scons mode=debug.