[Scons-users] Weird problem in MS Windows
Albert Arquer
albert.arquer at gmail.com
Thu Nov 2 09:44:34 EDT 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171102/24d953a8/attachment-0001.html>
More information about the Scons-users
mailing list