Closed MichaelBelousov closed 4 years ago
Just encountered the same problem. I modified the scons/SCons/Tool/MSCommon/common.py
to print the error correctly and there were multiple lines of "The system cannot find the path specified.". I guess it related to my system environment settings but I didn't want to go deeper on that. Eventually, I just reset the Windows with "remove everything" option, and the problem solved.
@FIF15
a) does --debug=stacktrace
do the same thing for scons?
b) Could you elaborate on what you mean by "reset windows", you mean you performed "Reset this PC" and reinstalled the operating system? I'm not sure that's a [good] option for me.
Please try : pip install -i https://test.pypi.org/simple/ SCons==3.9.9a991
That's a fairly recent development build of SCons.
It's likely your issue has been resolved.
You'll need python 3.5 or newer to run this version.
3.0.5, 3.1.0, 3.1.1, 3.1.3 fail the same way as 3.1.2 3.9.9a991 and 3.9.9a99 fail like so:
$ scons
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 193, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "C:/msys64/mingw64/bin/scons.exe/__main__.py", line 4, in <module>
ModuleNotFoundError: No module named 'SCons'
what is scons.exe/__main__.py
? this looks like something from msys, not the scons you installed via pip.
@MichaelBelousov - that was pip install via msys2's python version > 3.5?
System installed scons (msys2/mingw64/pacman) was uninstalled, I installed using the system pip, which is definitely tied to the one and only python interpreter I have installed on this new msys2 installation, and is python 3.8.
Mike@DESKTOP ~ (master) 20:24:18.348
$ pacman -Qo python
error: No package owns /mingw64/bin/python # I guess only explicit packages are checked?
Mike@DESKTOP ~ (master) 20:24:25.761
$ python -V
Python 3.8.2 # only installed python version
Mike@DESKTOP ~ (master) 20:24:29.091
$ pacman -Qe | grep python # explicitly installed python packages
mingw-w64-i686-python-pip 20.0.2-1
mingw-w64-x86_64-python-pip 20.0.2-1
Mike@DESKTOP ~ (master) 20:25:06.783
$ pacman -Qk scons # demonstrating scons is not installed
error: package 'scons' was not found
Full example:
Mike@DESKTOP /d/gamedev/game (master) 20:27:48.014
$ pacman -R scons
error: target not found: scons
Mike@DESKTOP /d/gamedev/game (master) 20:29:16.329
$ python -V
Python 3.8.2
Mike@DESKTOP /d/gamedev/game (master) 20:29:31.004
$ python -m pip install -i https://test.pypi.org/simple/ Scons==3.9.9a99
Looking in indexes: https://test.pypi.org/simple/
Collecting Scons==3.9.9a99
Downloading https://test-files.pythonhosted.org/packages/5c/4d/4aa5d7c370d55d3049394b8ada75f9560b5e8f8a6d904d9ebf79fab9754c/SCons-3.9.9a99-py3-none-any.whl (4.0 MB)
|████████████████████████████████| 4.0 MB 3.3 MB/s
Requirement already satisfied: setuptools in c:/msys64/mingw64/lib/python3.8/site-packages (from Scons==3.9.9a99) (46.1.3)
Installing collected packages: Scons
Attempting uninstall: Scons
Found existing installation: scons 3.1.0
Uninstalling scons-3.1.0:
Successfully uninstalled scons-3.1.0
Successfully installed Scons-3.9.9a99
Mike@DESKTOP /d/gamedev/game (master) 20:30:20.888
$ scons
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 193, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:/msys64/mingw64/lib/python3.8/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "C:/msys64/mingw64/bin/scons.exe/__main__.py", line 4, in <module>
ModuleNotFoundError: No module named 'SCons'
Here's what I get:
$ pip install -i https://test.pypi.org/simple/ SCons==3.9.9a991
Looking in indexes: https://test.pypi.org/simple/
Collecting SCons==3.9.9a991
Downloading https://test-files.pythonhosted.org/packages/56/66/22db0e689b1d3af5b79c7beb56201a2d21debd833498a5eee760b3e22b54/SCons-3.9.9a991-py3-none-any.whl (4.0 MB)
|################################| 4.0 MB 3.3 MB/s
Requirement already satisfied: setuptools in c:/msys64/mingw64/lib/python3.8/site-packages (from SCons==3.9.9a991) (46.1.3)
Installing collected packages: SCons
Successfully installed SCons-3.9.9a991
Bill@HEXADOG MINGW64 ~
$ which scons
/mingw64/bin/scons
Bill@HEXADOG MINGW64 ~
$ scons --version
SCons by Steven Knight et al.:
engine: v__VERSION__.__BUILD__, __DATE__, by __DEVELOPER__ on __BUILDSYS__
engine path: ['C:/msys64/mingw64/lib/python3.8/site-packages/SCons']
__COPYRIGHT__
Bill@HEXADOG MINGW64 ~
$ cd godot/
Bill@HEXADOG MINGW64 ~/godot
$ scons
scons: Reading SConscript files ...
scons: warning: EnsureSConsVersion is ignored for development version
File "C:/msys64/home/Bill/godot/SConstruct", line 3, in <module>
Automatically detected platform: windows
Configuring for Windows: target=debug, bits=default
Found MSVC version 14.2, arch amd64, bits=64
Checking for C header file mntent.h... no
scons: done reading SConscript files.
scons: Building targets ...
[Initial build] scons: *** [core/method_bind.gen.inc] Implicit dependency `core/platform_methods.py' not found, needed by target `core/method_bind.gen.inc'.
scons: building terminated because of errors.
@MichaelBelousov - any chance you can hop on SCons' discord server or IRC channel? discord: https://discord.gg/bXVpWAy IRC: is #scons on freenode
did a deep dive with @bdbaddog, got past the scons issues by explicitly uninstalling the pip version (pip uninstall scons
) then explicitly installing 3.99 via pip again.
Still not past the Error 1
during build, but it's due to windres landing on:
$ windres --include-dir . -i platform/windows/godot_res.rc -o platform/windows/godot_windows.windows.tools.64.o
The system cannot find the path specified.
C:\msys64\mingw64\bin\windres.exe: preprocessing failed.
EDIT: no, uninstalling explicitly did not fix it. Turned out Visual Studio Build tools being installed caused it.
couple of notes so far:
cp platform_methods.py core
satisfied an unfound request for platform_methods.py in a script in core/--use-temp-file
option to the windres
command occurring on line 87 of platform/windows/detect.py
stops windres from erroring out, but there's still the Error 1
errorSo it looks like that windres
call is still outputting to stderr according to the POpen.communicate call. When executing:
windres --include-dir . --use-temp-file -i platform/windows/godot_res.rc -o platform/windows/godot_res.windows.tools.64.o
stdout = None stderr = b'The system cannot find the path specified.\r\n'
The command executes fine in msys shell
I assume because of some weird path resolution on msys: removing shell=True
from the Popen
call (in addition to the adding of --use-temp-file
seems to have fixed it.
Turns out that windres writes to stderr "Preprocessing failed" and "cannot find the path specified" if you do not use --use-temp-file, but if shell=True
it also writes another "cannot find the path specified". So there were two of those messages, so removing both --use-temp-file and shell=True fixed both of those. Perhaps resolving the paths in code will still allow shell=True
to be used.
I'll wait for some input from someone who has insight on those specific build commands. For now I've attached a patch of the changes (small changes to platform/windows/detect.py and copying the platform_methods.py) patch.txt
Also I'm trying to compile with mono support and SCons's Dir
object fails to detect absolute paths in paths containing back slashes (in 3.99), so I have to manually pass the mono_prefix with forward slashes
More specifically, Godot gets the mono installation path from the windows registry, and if using msys2, you need to convert that path to a unix path for the msys2 python to work as expected. That might be worth a PR.
Also looks like the original stack trace about "write() argument must be str, not bytes" was due The build script not handling having visual studio build tools installed, but not the whole visual studio IDE. Supporting the builds tools might also be worthy of a PR.
Nope, installing the IDE as well did not fix it, I guess I'll fully debug it.
@FIF15 a) does
--debug=stacktrace
do the same thing for scons? b) Could you elaborate on what you mean by "reset windows", you mean you performed "Reset this PC" and reinstalled the operating system? I'm not sure that's a [good] option for me.
a) I'm not sure about that. b) Yes, I meant "Reset this PC". I'm sorry this is not a option for you and hope you will find out another way out soon. I tried to solve the problem, but didn't get any clue. So I stopped debugging at some point to move on to the work I planned to do with Godot.
i see you trying out different versions of stuff...
maybe it helps, i have Win10 x64, MSVC 2019, Scons 2.4.1, Python 2.7.11, and it works like a charm for both new godot 3.2 and good old 2.1
then when you have it all, you gota
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
cd godot-3.2
call scons -j5 platform=windows tools=yes target=release_debug vsproj=yes
i also dont have anything special in PATH just
C:\Program Files (x86)\Python27\
C:\Program Files (x86)\Python27\Scripts
Alright, I appear to have found the problem with my environment! In fact, I'll probably go back at some point today and confirm whether any of the changes I made are needed now, and then close the issue.
Firstly, I found that vcvarsall.bat was yielding an error code of 1 and spitting multiple "file not found" lines to stderr while SCons tries to locate vsbuild tools. I opened up VS's developer command prompt. And I noticed that any command prompt I open, at the top it declares "file not found". And I realized that I installed Clink for cmd like 4 years ago thinking it would help the times I need to use cmd, but I learned quickly I basically never need to use cmd. Last week I uninstalled it, and I don't believe I uninstalled it in the intelligent way, so I think cmd was broken by missing clink files it expected. I reinstalled clink and it seems to have repaired that, and I can uninstall clink correctly too probably. vsvars is now fine, vs build tools are recognized by scons, and I think that's all I needed, I'll be running builds to see if I run into the windres problem again.
yup, I removed my changes and it looks like none of them are necessary at all, I'll close this issue. The only other problems I may have ran into were mono related and if I still have them, I may make a separate issue.
Godot version: 3.2 branch, hash: ed27b7e6 master 28f0b15c
OS/device including version: Windows 10 Home 10.0.18362
Issue description: SCons build fails with both msys/scons or pip-installed scons, on a fresh installation of msys2 using the mingw64 subsystem. Will post more env info as needed:
Python Version: (default msys2 as of today) 3.8.2 Msys explicitly installed packages:
Steps to reproduce:
mingw-w64-x86_64-python3-pip mingw-w64-x86_64-gcc mingw-w64-x86_64-yasm mingw-w64-i686-python3-pip mingw-w64-i686-gcc mingw-w64-i686-yasm make
pip install scons
orpython -m pip install scons
scons platform=windows
result:Alternatively uninstall that scons, and install the msys/scons and try building again:
scons platform=windows
result:Minimal reproduction project: 3.2 branch, hash: ed27b7e6 master 28f0b15c