Scons无法导入_args_from_interpreter_flags

Question

我试图按照戈多发动机指令编译这里

如本教程所述，当我运行scons bin/godot时，会得到以下错误：

scons: Reading SConscript files ...
ImportError: cannot import name _args_from_interpreter_flags:
  File "/home/grayfox/github/godot2/godot/SConstruct", line 9:
    import multiprocessing
  File "/usr/lib64/python2.7/multiprocessing/__init__.py", line 65:
    from multiprocessing.util import SUBDEBUG, SUBWARNING
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 40:
    from subprocess import _args_from_interpreter_flags

SConstruct文件是这样开始的：

EnsureSConsVersion(0,14);

import string
import os
import os.path
import glob
import sys
import methods
import multiprocessing
...

如果我试图运行python SConstruct，就会收到一个错误，抱怨scon定义的函数缺失(即脚本在执行所有导入之后失败了)。

注释import multiprocessing修复了这个问题，但我不想修改该文件，因为如果我提出拉请求，我将不得不恢复更改。这个项目非常活跃，所以我相信这与我的本地配置有关。

知道为什么只有当我通过scon执行脚本时，脚本才不能导入_args_from_interpreter_flags？

更新

我做了一个新的Gentoo安装，问题仍然存在。我做了一些测试发现了这个：

在python terminal>中

>>> import SCons.Script
>>> from subprocess import _args_from_interpreter_flags
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name _args_from_interpreter_flags
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/site-packages/SCons/compat/_scons_subprocess.pyc'

但是如果我这样做的话，输出就不一样了：

>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/subprocess.pyc'

所以我更新我的问题:这是一个bug吗？有人能在其他发行版中复制吗？如果是bug，我应该向Gentoo报告还是向SCons报告？

另一个更新

添加temp.extend([os.path.join(x, 'lib64') for x in prefs])不起作用，同样的错误。

在紧凑型模块的开头添加print sys.path将提供如下结果：

['/usr/lib64/python-exec/python2.7/scons-local-2.3.0',
 '/usr/lib64/python-exec/python2.7/scons-local',
 '/usr/lib64/python2.7/site-packages/lib32/scons-2.3.0',
 '/usr/lib32/scons-2.3.0',
 '/usr/local/lib32/scons-2.3.0',
 '/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/local/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/lib64/scons-2.3.0',
 '/usr/lib64/python2.7/site-packages/lib32/scons',
 '/usr/lib32/scons',
 '/usr/local/lib32/scons',
 '/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons',
 '/usr/lib/python2.7/site-packages/scons',
 '/usr/local/lib/python2.7/site-packages/scons',
 '/usr/lib64/scons',
 '/usr/lib64/python2.7/site-packages/RBTools-0.6-py2.7.egg',
 '/usr/lib64/python27.zip',
 '/usr/lib64/python2.7',      #It's here, so what's the problem?
 '/usr/lib64/python2.7/plat-linux2',
 '/usr/lib64/python2.7/lib-tk',
 '/usr/lib64/python2.7/lib-old',
 '/usr/lib64/python2.7/lib-dynload',
 '/usr/lib64/python2.7/site-packages',
 '/usr/lib64/python2.7/site-packages/gtk-2.0',
 '/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode']

Answer 1

它是Gentoo scons-2.3.0和skes-2.3.1eBuilds中的一个bug (参见错误报告)。它已在2.3.1-r1版本和更高版本中得到修正。

Answer 2

看起来这并不是一个与SCons直接相关的问题。您可能在系统中安装了一个外星“子进程”模块/包。还可以查看标志，它似乎是相关的。

基于您更新的问题:我尝试在我的机器(Python2.7.3、SCons 2.3.1、Ubuntu12.04LTS)上编译Godot，并且运行良好，所以这个问题与提供的SConstruct (以及它在子文件夹中支持的构建描述文件)无关。只有在导入原始"_scons_subprocess“失败时才使用"subprocess.py”模块。因此，我怀疑SCons启动脚本设置了一个错误的sys.path，这可能发生在64位以下(参见suspect bug.cgi?id=2657 )。

在添加"temp.extend([os.path.join(x, 'lib64') for x in prefs])“之后，"print sys.path”语句在其输出中显示“/usr/lib64 64/python”之类的路径。谷歌搜索为我打开了http://forums.gentoo.org/viewtopic-t-985402-start-0.html页面。它描述了Gentoo的一个问题，在Gentoo中，程序是作为pip链接安装的。请遵循给出的建议，看看这是否解决了你的问题。