[Scons-users] Importing Module That is a Build Product

[Fred Wright]

On Thu, 15 Sep 2016, William Blevins wrote:

> I think this is a bit dangerous honestly. Since the SConstructs/SConscripts
> always get parsed first, this will always have an odd effect. If you try to
> do a full build without "A.py", an ImportError will happen. If "A.py" needs
> to rebuild, then the old import will be loaded. I would never try to import
> a file generated within the build process.

That's true if the import happens as a part of direct execution in the
SConstruct script, but not if it's part of a builder, which isn't run
until the parsing and dependency analysis is complete.

> What does the imported script do? It would be better if the imported script
> was invoked on the shell as the action, rather than running the script
> within SCons itself. This also has the benefit of being a true action which
> means that it will run in parallel in a new shell rather than doing work
> inside the SConscript if the action is expensive.

I think the real issue here is something different:  Although SCons adds
SConstruct's directory to sys.path prior to running it, it undoes that
change prior to running the builders, which means that the script
directory isn't included in the module search path during the latter
phase.  I'm not sure what the rationale is for the "undo" but it's
certainly a source of trouble. :-)

Running via the shell in fact fixes it, but for a different reason:  When
Python runs a .py file, it adds the file's directory to sys.path, so that
it can find any modules in the same directory.  This is a sufficient but
not necessary approach.

As far as parallelism goes, it depends on whether it's limited to external
programs, or whether the builder functions themselves are parallelized.
If the latter, than any appraoch that fixes the import problem would be
just as good.

Fred Wright