[Scons-users] Weird problem in MS Windows

Albert Arquer albert.arquer at gmail.com
Thu Nov 2 13:37:36 EDT 2017 

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171102/276a6cf2/attachment-0001.html>

More information about the Scons-users mailing list