views:

267

answers:

2

I have an SCons project set up as follows:

Project/
    SConstruct  # "SConscript('stuff/SConscript', variant_dir = 'build')
    stuff/
        SConscript # "import configuration"
        configuration/
            __init__.py
            Thing.py

When building, the SConscript is copied to the build directory, but the "configuration" module is not. Ordinarily, one would express a file dependency with the Depends() function (e.g. Depends(program, object_files)). In this case, though, the SConscript file is itself the "target" of the dependency.

How do I express this in my SConscript?

+1  A: 

I have two workarounds for you. I call them workarounds because they don't express the dependency in the SConscript.

  1. Do the 'import configuration' from your SConstruct (you'll need to edit sys.path)

  2. In stuff/SConscript, add the source directory to sys.path:

    
    import sys
    sys.path += ['%s/stuff' % (Dir('#').abspath)]

    import configuration
Dave Bacher
#2 totally worked. Thanks!
Andres Jaan Tack
A: 

Firstly, do you really need dependence on your SCons script source files? How often do they change, and if they change is it really so onerous to require that your user does a clean build if they muck with the SConscript.py configuration file(s).

If you do require this, are you currently not seeing this? I've found SCons to be rather good at knowing if and how the SConscript.py files have changed. Specifically, if you have any user defined builders with custom action python functions? For my EDA build flow which has scads of user-defined python functions which call the myriad of proprietary EDA tools, if I change any SConstruct.py file, all the results of my custom python builders are assumed to be invalid (must to my chagrin, often). FYI, I'm using release 1.2.0.d20090223.

Ross Rogers
It's not so critical that the build be regenerated, but more that the path for the import is available to the SConscript in the build directly. My current error is, "No module named configuration."
Andres Jaan Tack
Oh, I see. In our flow, we have an environment variable which specifies the root of the sandbox. The other thing I found was you want to wrapper the scons call so you do a <CODE>cd $SANDBOX</CODE> and then call scons. ( there may be a way to accomplish this in scons, but I wanted to pass in some default options to scons as well -- options for which scons will not allow you to use method SetOption e.g. 'num_jobs' option)
Ross Rogers