[Scons-users] Weird problem in MS Windows

Bill Deegan bill at baddogconsulting.com
Fri Nov 3 12:19:23 EDT 2017 

Albert,

Yes. The DefaultEnvironment() is always initialized.
It will initialize the default list of tools unless you specify otherwise.
-Bill

On Fri, Nov 3, 2017 at 7:32 AM, Albert Arquer <albert.arquer at gmail.com>
wrote:

> Hi Bill,
>
> could this still be the cause considering I already have no tools in the
> environment I am instantiating? (see my previous e-mail).
> I mean, if the environment already has no tools in it, there should not be
> any tools being initialized right?
>
> -Albert.
>
> 2017-11-02 20:37 GMT+01:00 Bill Deegan <bill at baddogconsulting.com>:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20171103/6f4ee4fd/attachment-0001.html>

More information about the Scons-users mailing list