[Scons-users] Weird problem in MS Windows
Albert Arquer
albert.arquer at gmail.com
Fri Nov 3 10:32:57 EDT 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171103/398b294b/attachment-0001.html>
More information about the Scons-users
mailing list