[Scons-users] Weird problem in MS Windows
Luke Tunmer
luke.tunmer at gmail.com
Thu Nov 2 11:10:28 EDT 2017
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171102/da80cecd/attachment-0001.html>
More information about the Scons-users
mailing list