[Scons-users] Weird problem in MS Windows

Bill Deegan bill at baddogconsulting.com
Thu Nov 2 15:37:37 EDT 2017 

Luke is correct, though I'm pretty sure you shouldn't need to specify the
package path (SCons.Defaults.DefaultEnvironment()).
(At least if you do it in a SConstruct or SConscript)

There is always a DefaultEnvironment().
So, if you add:

DefaultEnvironment(tools=[]) to your top level SConstruct, it should never
initialize any tools in the default environment, and thus avoid the issue
in your stack trace.

  File "C:\Python27\Lib\site-packages\scons-2.5.1\SCons\Defaults.py", line
> 88, in DefaultEnvironment
>     _default_env = SCons.Environment.Environment(*args, **kw)
>   File "C:\Python27\Lib\site-packages\scons-2.5.1\SCons\Environment.py",
> line 982, in __init__
>     apply_tools(self, tools, toolpath)
>   File "C:\Python27\Lib\site-packages\scons-2.5.1\SCons\Environment.py",
> line 107, in apply_tools
>     env.Tool(tool)
>

Give it a try and let us know if the problem reappears.

-Bill
SCons Project Co-Manager


On Thu, Nov 2, 2017 at 7:37 AM, Albert Arquer <albert.arquer at gmail.com>
wrote:

> I am affraid I misspoke when I said that giving tools = [] to the
> environment instance had no effect.
>
> I have been checking the output of env.Dump() and my environments seem to
> have no "TOOLS" at all. I have not changed any of this lately so the bug I
> reported happens even when no tools are loaded into the environment I
> guess...
>
> -Albert.
>
>
> 2017-11-02 16:10 GMT+01:00 Luke Tunmer <luke.tunmer at gmail.com>:
>
>> Hi Albert,
>>
>> I think what happens is that when the first environment is made, it
>> clones from a singleton DefaultEnvironment with has a default set of tools,
>> which includes the msvc tool on Windows. By making the DefaultEnvironment
>> yourself before any other environments you can force it to have an empty
>> set of tools. Which, from my perspective, I prefer: better to be explicit
>> and add particular tools when you need them rather have bizarre tools
>> instantiated that you don't expect. This is one of the few things that I
>> think SCons has got wrong.
>>
>> Regards
>> Luke
>>
>>
>> On 2 November 2017 at 13:44, Albert Arquer <albert.arquer at gmail.com>
>> wrote:
>>
>>> Hi Luke,
>>>
>>> thanks, but I believe the way I am using the Environment might be
>>> different...
>>>
>>> As I said I have my own class (called HDLEnvironment) which inherits
>>> from SCons.Environment.Environment.
>>>
>>> Then what I do is I instantiate multiple Environments, one for each "top
>>> target" I have.
>>> For example I might have a top target which is a simulation, and another
>>> top target which is a synthesis. Having different customized Environments
>>> for each allows me to declare targets in a "generic" way, for example,
>>> "make_module( targets = ..., source = ..., ...)" might use different
>>> builders depending on the top target's environment. In a simulation it
>>> might call the compiler, while in a synthesis it might just create a TCL
>>> script which adds sources into the EDA Tool's environment.
>>>
>>> Now imagine I make a new type of top target which I call "archive", with
>>> which I want to use for zipping sources. With this approach I only have to
>>> write a new builder which instead of compiling or creating a TCL scripts,
>>> generates a zip file and assign the "make_module" method to that new
>>> builder.
>>>
>>> I don't know if this problem could be caused because of having multiple
>>> environment instances... What do you think Bill?
>>>
>>> -Albert.
>>>
>>> 2017-11-02 13:17 GMT+01:00 Luke Tunmer <luke.tunmer at gmail.com>:
>>>
>>>> Albert,
>>>>
>>>> For similar reasons (we compile code for embedded environments with a
>>>> whole slew of different C compilers) I also wanted to prevent SCons from
>>>> looking for an installed MSVC. I achieved this by calling:
>>>>
>>>>     SCons.Defaults.DefaultEnvironment(tools=[]) # stop MSVC complaints
>>>> on windows
>>>>
>>>> in a package that needs to be called before the first call to create an
>>>> environment.
>>>>
>>>> Not sure if that is the right thing to do, but it did stop scons from
>>>> attempting to find an msvc install.
>>>>
>>>> Then if our components need to re-enable a compiler like msvc they need
>>>> to add this:
>>>>
>>>>     for t in ['msvc', 'mslink', 'mslib']:
>>>>         env.Tool(t)
>>>>
>>>> to the env that was created. Interestingly the mingw compiler can be
>>>> added back into the env with just:
>>>>
>>>>     env.Tool('mingw')
>>>>
>>>> We also have other C compilers (for ARM and other propriety processors)
>>>> for which we have got SCons tools to introduce them into the environment.
>>>>
>>>> Regards,
>>>> Luke
>>>>
>>>>
>>>>
>>>> On 2 November 2017 at 11:50, Albert Arquer <albert.arquer at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bill,
>>>>>
>>>>> I might try SCons 3.0.0 when I get a chance, but I don't have time
>>>>> right now. Besides as I said there is no easy way to know if the issue is
>>>>> fixed unless the underlying cause is identified.
>>>>>
>>>>> I would definatelly like to remove c++/visual studio from the tool
>>>>> list (I am not using any of them, I use EDA tools which I manage manually
>>>>> through a derived class from Environment). When I instantiate the
>>>>> Environment I already do it with "tools=[]" but that seems to have no
>>>>> effect.
>>>>> I don't really know what you mean with the DefaultEnvironment(). As I
>>>>> stated above I have a custom class deriving from
>>>>> SCons.Environment.Environment and that is what I use.
>>>>>
>>>>> -Albert.
>>>>>
>>>>> 2017-10-31 20:03 GMT+01:00 Bill Deegan <bill at baddogconsulting.com>:
>>>>>
>>>>>> Albert,
>>>>>>
>>>>>> SCons 3.0.0 does not require python 3.0. It is compatible with python
>>>>>> 2.7.x and 3.5+
>>>>>> (though it requires changing print's to print()'s (until 3.0.1 is
>>>>>> released any day now))
>>>>>>
>>>>>> Are you using visual c++/visual studio to build your project?
>>>>>> (If not you could remove that from the list of tools being
>>>>>> initialized, and then see if another tool fails the same way)
>>>>>>
>>>>>> Are you using the DefaultEnvironment() on purpose?
>>>>>> (Via builders not attache to an Environment() such as Program()
>>>>>> instead of env.Program())
>>>>>>
>>>>>> -Bill
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 30, 2017 at 11:46 PM, Albert Arquer <
>>>>>> albert.arquer at gmail.com> wrote:
>>>>>>
>>>>>>> No easily...
>>>>>>> All my sconscripts are in python 2.x. As I said this problem is
>>>>>>> intermittent, so it is not just testing it once, it would mean using it for
>>>>>>> a long time....
>>>>>>>
>>>>>>> Also, without identifying the underlying problem... how will we know
>>>>>>> if it is actually fixed? Sometimes this error does not appear for weeks.
>>>>>>>
>>>>>>> 2017-10-31 3:37 GMT+01:00 Bill Deegan <bill at baddogconsulting.com>:
>>>>>>>
>>>>>>>> Can you try SCons 3.0.0?
>>>>>>>>
>>>>>>>> On Mon, Oct 30, 2017 at 3:40 AM, Albert Arquer <
>>>>>>>> albert.arquer at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I have been battling with an SCons issue (at least that is what I
>>>>>>>>> believe it is). This problem is intermittent, however it only seems to
>>>>>>>>> appear when I build targets with the "-j" option, launching multiple
>>>>>>>>> threads.
>>>>>>>>>
>>>>>>>>> You can see the error trace here:
>>>>>>>>>
>>>>>>>>> scons: *** [<target_path>] AttributeError : 'module' object has no
>>>>>>>>> attribute 'exists'
>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Taskmaster.py", line 234, in execute
>>>>>>>>>     if not t.retrieve_from_cache():
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Node\FS.py", line 2935, in retrieve_from_cache
>>>>>>>>>     return self.get_build_env().get_CacheDir().retrieve(self)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Environment.py", line 1010, in get_CacheDir
>>>>>>>>>     path = SCons.Defaults.DefaultEnvironment()._CacheDir_path
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Defaults.py", line 88, in DefaultEnvironment
>>>>>>>>>     _default_env = SCons.Environment.Environment(*args, **kw)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Environment.py", line 982, in __init__
>>>>>>>>>     apply_tools(self, tools, toolpath)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Environment.py", line 107, in apply_tools
>>>>>>>>>     env.Tool(tool)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Environment.py", line 1789, in Tool
>>>>>>>>>     tool(self)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Tool\__init__.py", line 197, in __call__
>>>>>>>>>     self.generate(env, *args, **kw)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Tool\default.py", line 40, in generate
>>>>>>>>>     for t in SCons.Tool.tool_list(env['PLATFORM'], env):
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Tool\__init__.py", line 1108, in tool_list
>>>>>>>>>     linker = FindTool(linkers, env) or linkers[0]
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Tool\__init__.py", line 993, in FindTool
>>>>>>>>>     t = Tool(tool)
>>>>>>>>>   File "C:\Python27\Lib\site-packages
>>>>>>>>> \scons-2.5.1\SCons\Tool\__init__.py", line 113, in __init__
>>>>>>>>>     self.exists = module.exists
>>>>>>>>> AttributeError: 'module' object has no attribute 'exists'
>>>>>>>>> scons: building terminated because of errors.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Basically scons seems to fail while loading built-in tools,
>>>>>>>>> specifically during loading of the "mslink" python module, which I assume
>>>>>>>>> is something specific to microsoft windows.
>>>>>>>>> I have tried to narrow it down and have found very little
>>>>>>>>> coherency, for example, if I print the object's attributes, methods, etc.
>>>>>>>>> right before scons fails by putting the following code on the Tool.__init__
>>>>>>>>> method in SCons/Tool/__init__.py:
>>>>>>>>>
>>>>>>>>>             print("Class of module is:
>>>>>>>>> {}".format(module.__class__))
>>>>>>>>>             print("Name is: {}".format(module.__name__))
>>>>>>>>>             print("File is: {}".format(module.__file__))
>>>>>>>>>             print("Doc is: {}".format(module.__doc__))
>>>>>>>>>             print dir(module)
>>>>>>>>>
>>>>>>>>> I get the following:
>>>>>>>>>
>>>>>>>>> Class of module is: <type 'module'>
>>>>>>>>> Name is: SCons.Tool.mslink
>>>>>>>>> File is: C:\Python27\Lib\site-packages\
>>>>>>>>> scons-2.5.1\SCons\Tool\mslink.pyc
>>>>>>>>> Doc is: SCons.Tool.mslink
>>>>>>>>>
>>>>>>>>> Tool-specific initialization for the Microsoft linker.
>>>>>>>>>
>>>>>>>>> There normally shouldn't be any need to import this module
>>>>>>>>> directly.
>>>>>>>>> It will usually be imported through the generic SCons.Tool.Tool()
>>>>>>>>> selection method.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ['RegServerFunc', 'SCons', '__builtins__', '__doc__', '__file__',
>>>>>>>>> '__name__', '__package__', '__revision__', '_dllEmitter', '_dllSources',
>>>>>>>>> '_dllTargets', '_windowsLdmodSources', '_windowsLdmodTargets',
>>>>>>>>> 'embedManifestDllAction', 'embedManifestDllCheck',
>>>>>>>>> 'embedManifestDllCheckAction', 'embedManifestExeAction',
>>>>>>>>> 'embedManifestExeCheck', 'embedManifestExeCheckAction', 'ldmodEmitter',
>>>>>>>>> 'msvc_exists', 'msvc_setup_env_once', 'os', 'pdbGenerator', 'prog_emitter',
>>>>>>>>> 'regServerAction', 'regServerCheck', 'shlibLinkAction',
>>>>>>>>> 'windowsLibEmitter', 'windowsShlinkSources', 'windowsShlinkTargets']
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> As you can see the __doc__ text matches the one found in the
>>>>>>>>> "mslink" file, however for some reason the "generate" method is not
>>>>>>>>> available and python crashes when it is called...
>>>>>>>>>
>>>>>>>>> Does anybody have an idea of what could this be due to? I remember
>>>>>>>>> when I installed SCons and launched targets with the -j switch SCons
>>>>>>>>> advised me to install some package for windows, which I did, I don't
>>>>>>>>> remember the package's name right now.
>>>>>>>>>
>>>>>>>>> In absence of a better solution I wonder if it would be possible
>>>>>>>>> to stop scons from loading any of those tools, as I don't think I am using
>>>>>>>>> any of them... This would only be an option if it could be done without
>>>>>>>>> modifiying the SCons source code.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20171102/36151264/attachment-0001.html>

More information about the Scons-users mailing list