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

Bill Deegan bill at baddogconsulting.com
Thu Sep 15 18:35:00 EDT 2016


Can you explain what this module's function is?
Any reason you must generate file and then run it?

Could you eval the logic (I know it's not recommended, but it's effectively
what's being done here anyway)

-Bill

On Thu, Sep 15, 2016 at 2:28 PM, Fred Wright <fw at fwright.net> wrote:

>
> 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
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160915/eb1b5ca8/attachment.html>


More information about the Scons-users mailing list