[Scons-users] Importing Module That is a Build Product
Keith Prussing
kprussing74 at gmail.com
Thu Sep 15 15:50:55 EDT 2016
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
More information about the Scons-users
mailing list