I have non system headers, which I use to compile a program via SCons. Problem is they sometimes change but SCons does not seem to scan for changes in the headers at all.
Is there a way to tell SCons to scan the headers for changes?
Assuming you're talking about c/c++, SCons should always scan the header files, assuming the include paths have been correctly set to do so.
If the include paths have been specified with the CPPPATH construction variable, then the include files in that path will be scanned for changes. The include paths specified with this variable should not have the -I prepended, as SCons will do that in a portable manner.
This variable can be appended to as follows:
env = Environment()
# These paths WILL BE scanned for header file changes
env.Append(CPPPATH = ['path1', '/another/path', 'path3'])
If the include paths have been specified in the CCFLAGS or CXXFLAGS construction variables, then the include files in that path will not be scanned for changes. The include paths specified in either one of these variables must have the -I prepended. This approach is beneficial when specifying system header include paths that will most likely never change, thus speeding up the build process.
Paths can be appended to the CXXFLAGS variable:
env = Environment()
# These paths will NOT be scanned for header file changes
env.Append(CXXFLAGS = ['-Ipath1', '-I/another/path', '-Ipath3'])
Here is a list of the rest of the SCons construction variables.
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 want to know where in the code buildroot exports the configuration symbols so that they can be read in the .mk for each package:
Example:
In the package exim.mk there is a test on BR2_PACKAGE_OPENSSL value:
ifeq ($(BR2_PACKAGE_OPENSSL),y)
The symbol is defined in the .config, but how exim.mk read it
Buildroot is based on the make build system. make reads in the top-level Makefile, and parses the include directives in that file. One such directive is
-include $(BR2_CONFIG)
The BR2_CONFIG variable expands to .config (either in the Buildroot directory, or in the output directory if O= is given). The .config file contains all the configuration options that you selected using the Kconfig infrastructure.
Next, the top-level Makefile has
include $(sort $(wildcard package/*/*.mk))
This reads in all the .mk files in the package directory, including exim.mk. So when exim.mk is parsed, the BR2_PACKAGE_OPENSSL value set in .config will be evaluated. This can be either
BR2_PACKAGE_OPENSSL=y
if the option was selected, or
# BR2_PACKAGE_OPENSSL is not set
if it was not selected. So the condition will be true in the first case and false in the second case.
I'm building code with multiple environments, outputting to multiple target directories. The natural way to manage this seems to be with variant directories. So I might want to build the same set of files multiple times with different options and different VariantDirs. So I want to be able to have multiple SConscript files in different locations, all referring back to the same source directory.
One option I've tried is to do this:
SConstruct
src/test.cpp
src/magic/SConscript
This is my SConstruct:
env = Environment()
SConscript('src/magic/SConscript',
variant_dir = 'build/src',
src_dir = 'src',
exports={'env':env},
duplicate=0)
and this is src/magic/SConscript:
Import('env')
source = 'test.cpp'
env.Object(source)
I get this output:
scons: *** [build/src/magic/test.o] Source `src/magic/test.cpp' not found, needed by target `build/src/magic/test.o'.
This looks like both the variant_dir and src_dir are not being respected by Object, since neither mention magic at all.
Have I misunderstood how variant_dir/src_dir are meant to work, and what is the best way to build the same set of files with different targets?
Your file/folder hierarchy doesn't fit the build specification in your SConstruct/SConscript files.
Note how file paths in SCons are usually relative to the location of the current SConscript, so:
source = 'test.cpp'
env.Object(source)
in src/magic/SConscript gets expanded to src/magic/test.cpp...which obviously doesn't exist. You could use ../test.cpp as filename, or move the SConscript one up from src/magic to the src folder directly.
Some further remarks:
1.) When you specify a path for the name of the SConscript file in the SConscript call:
SConscript('src/SConscript',
variant_dir = 'build',
exports={'env':env},
duplicate=0)
SCons will automatically derive the src_dir argument from the path of the first argument.
2.) Please check out the chapter 14 "Hierarchical Builds" in the UserGuide ( http://www.scons.org/doc/production/HTML/scons-user.html ).
Suppose I have an SConstruct file that looks like this:
env = Environment()
env.Program("a", ["a.c", "util.c"])
env.Program("b", ["b.c", "util.c"])
This build works properly with no SCons warning messages. However, if I modify this to specify different libraries for each Program build (the actual libraries are not relevant):
env.Program("a", ["a.c", "util.c"], LIBS="m")
env.Program("b", ["b.c", "util.c"], LIBS="c")
then I get the warning:
scons: warning: Two different environments were specified for target util.o,
but they appear to have the same action: $CC -o $TARGET -c $CFLAGS $CCFLAGS $_CCCOMCOM $SOURCES
This appears to be caused by the Program builder automatically creating a new environment for building the sources, even though it is just the LIBS variable that is different (and so only the link step needs to have a different environment). I can work around this by doing something like:
util = env.Object("util.c")
env.Program("a", ["a.c"] + util, LIBS="m")
env.Program("b", ["b.c"] + util, LIBS="c")
This uses a single Object builder for building util.c, then using the precompiled object file in each Program build, thus avoiding the warning. However, this should not really be necessary. Is there a more elegant way to work around this problem? Or is this actually a bug in SCons that should be fixed?
Context: I have nearly 2000 C source files compiled into about 20 libraries and 120 executables with lots of shared sources. I created the SConstruct file from the previous proprietary build system using a conversion script I wrote. There are about 450 "Two different environments" warning messages produced by SCons for a full build using my current SConstruct.
I found a workaround that doesn't involve creating extra variables to hold the object file nodes:
env.Program("a", ["a.c", env.Object("util.c")], LIBS="m")
env.Program("b", ["b.c", env.Object("util.c")], LIBS="c")
This isolates the build of util.c within a single environment. Although it is specified twice, once for each Program, SCons doesn't warn about this because it's the same source built with the same env object. Of course SCons only compiles the source once in this case.
You may use the Split function and a custom helper to simplify the build process for large projects:
def create_objs(SRCS, path=""):
return [env.Object(path+src+".cpp") for src in SRCS]
prg1 = Split("file_1 file_2 file_N")
prg2 = Split("file_2 file_5 file_8")
env.Program("a", create_objs(prg1), LIBS="x")
env.Program("b", create_objs(prg2), LIBS="y")
The object files are created only once, and they can be used in multiple builds. Hope this helps...
One issue I found in my code was that I was not using the target object path correctly. Or in otherwords I had a variant dir directive, but instead of using BUILDPATH i ended up using my original source code path. This way Scons was finding the object generated in target BUILDPATH and source path.
Creating a static library out of the first set of files and linking the library to the next set of files (which have some files in common with the first set) to create a target works as well.
env.StaticLibrary ("a", ["a.c","util.c"], LIBS = "m")
env.Program ("b", ["b.c","util.c"], LIBS = ["c","a"])