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

William Blevins wblevins001 at gmail.com
Thu Sep 15 17:13:25 EDT 2016


Keith,

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.

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.

V/R,
William

On Thu, Sep 15, 2016 at 3:50 PM, Keith Prussing <kprussing74 at gmail.com>
wrote:

> William,
>
> You have the flow logic mostly right.  The key is the import happens
> within step 2.
>
> 1. Build A creates A.py.
> 2. Build B (a Python function) imports A.py and creates B.txt.
> 3. No top level imports of A.py
>
> When I thought to generate the module during the build, I realized the
> first pass would always fail if the main SConstruct/SConscript files
> imported the generated file.  My solution was to move the import
> statement into the Python function that is associated with Builder.
>
> The part that is confusing me is that the build fails with an import
> error every time if I don't fiddle with the module search path.  Even
> if I explicitly call `scons A.py` followed by `scons B.txt`, I get the
> import error.
>
> I'm mainly trying to understand why the import error is happening so I
> can put my SConsctruct files together in the neatest way possible.
>
> Keith
>
>
> On Thu, Sep 15, 2016 at 3:11 PM, William Blevins <wblevins001 at gmail.com>
> wrote:
> > Keith,
> >
> > I don't think this is related to module search path. Let me make sure I
> > understand.
> >
> > 1. Build A creates A.py.
> > 2. Build B takes source A.py and creates B.txt.
> > 3. SConstruct/SConscript containing Builder B imports A.py.
> >
> > This will always fail on the first iteration. SConstruct/SConscripts are
> > always parsed in full prior to any build step. A.py will never exist
> prior
> > to the import.
> >
> > V/R,
> > William
> >
> > On Thu, Sep 15, 2016 at 1:32 PM, Keith F Prussing <kprussing74 at gmail.com
> >
> > wrote:
> >>
> >> Hello,
> >>
> >> I am trying to understand the behavior of SCons when trying to import a
> >> module in one build rule that is the product of another build rule.
> >> Consider the following example SConstruct:
> >>
> >>    def writeit(target, source, env):
> >>        """Generate a mfe module."""
> >>        with open(str(target[0]), "w") as fid:
> >>            fid.write("string = 'hello'\nconst = 1\n")
> >>
> >>        return
> >>
> >>    def useit(target, source, env):
> >>        """Use the mfe module."""
> >>        # import imp, os
> >>        # path, base = os.path.split(os.path.realpath(str(source[0])))
> >>        # name, _ = os.path.splitext(base)
> >>        # file, pathname, description = imp.find_module(name, [path])
> >>        # imp.load_module(name, file, pathname, description)
> >>
> >>        import mfe
> >>        with open(str(target[0]), "w") as fid:
> >>            fid.write("{0}\n{1}\n".format(mfe.string, mfe.const+1))
> >>
> >>        return
> >>
> >>    test1 = Builder(action=writeit)
> >>    test2 = Builder(action=useit)
> >>
> >>    env = Environment(BUILDERS={"writeit" : test1, "useit" : test2})
> >>    mod = env.writeit(target=["mfe.py"], source=[])
> >>    out = env.useit(target=["test.txt"], source=mod)
> >>
> >> If I run this as is, the build for 'test.txt' will fail with an
> >> ImportError claiming that it cannot find 'mfe' even if I build 'mfe.py'
> >> explicitly before building 'test.txt'.  On the other hand, if there is a
> >> module in the current SConstruct directory, SCons will happily import
> that
> >> module with no problems.  My end goal is to generate a module of
> constants
> >> to use in the Python parts of my build from a source in a different
> language
> >> so that all pieces are using the same values.
> >>
> >> I suspected that the problem revolved around the module search path, so
> >> I played around and came up with the commented work around (lines
> >> 10-14).  With these lines uncommented, the build for 'test.txt' proceeds
> >> as expected.
> >>
> >> So, my question is: How does SCons establish the module search path?  Is
> >> there a better way to actually get the generated module imported?
> >>
> >> Searching for variations on 'scons import error' and 'scons import
> >> ignoring current directory' primarily turned up hits revolving around
> >> importing SCons components or where to put custom builders and tools.
> >>
> >>
> >> Keith
> >>
> >> --
> >> Keith F Prussing
> >> _______________________________________________
> >> Scons-users mailing list
> >> Scons-users at scons.org
> >> https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
> >
> >
> > _______________________________________________
> > Scons-users mailing list
> > Scons-users at scons.org
> > https://pairlist4.pair.net/mailman/listinfo/scons-users
> >
>
>
>
> --
> Keith Prussing
> _______________________________________________
> 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/f4b3fb2a/attachment.html>


More information about the Scons-users mailing list