29

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.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285

4 Answers4

20

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.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
10

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...

Flamínio Maranhão
  • 337
  • 4
  • 11
  • I voted this solution up because it does not require me to remember which environment each object is compiled into. All are compiled into a single environment. It also allows the SConscript file to be clean. I modified the create_obj function to NOT automatically append the .cpp suffix – Be Kind To New Users Feb 17 '13 at 17:29
1

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"])
Raghuraj Tarikere
  • 23
  • 3
1

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.

user210504
  • 1,749
  • 2
  • 17
  • 36