Yes, it should output more. (btw, no platform needed for that one):
~/work/defold $ ./scripts/build.py shell [issue-5128-dmsocket-dmsdk] 08:30:24
[exec] git remote get-url origin
Running 'shell'
Setting up shell with DYNAMO_HOME, PATH, ANDROID_HOME and LD_LIBRARY_PATH/DYLD_LIBRARY_PATH (where applicable) set
EDIT:
I don’t know if msys2 works here though (I don’t recall).
We’re creating a new shell, which it might fail?
Yeah I tried both Git Bash and MSYS2 but both have the same issue (not running the shell, simply running the git remote get-url origin command.) Not quite sure how to proceed from here.
The command isn’t very complex, it sets a few environment variables, then creates a shell.
You can ofc set those variables manually, or modify the command to not start a new shell. It’s in build.py
I’ve finally got the engine building and built the editor. However, when I run “lein init” I see
$ lein init
Initializing editor with version 'null', resolved to 'null'
Installing ../com.dynamo.cr/com.dynamo.cr.bob/lib/openmali.jar
Installing s:\defold_github\tmp\dynamo_home\share\java\bob.jar
java.nio.file.NoSuchFileException: s:\defold_github\tmp\dynamo_home\share\ref-doc.zip
at sun.nio.fs.WindowsException.translateToIOException (WindowsException.java:85)It looks like the documentation wasn’t built.
You might need to run that command too:
$ ./scripts/build.py build_docs
Thanks, I tried to run this but I see: ImportError: No module named script_doc_ddf_pb2
And you’ve built the engine successfully?
I think so, though not sure how to use it without the editor 
however I get this message:
Socket took 7.95754 s
Socket.GetHostByName_IPv4_Unavailable failed
Ran 48 tests, with 176 assertions in 7.95754 s
47 tests passed, 0 skipped and 1 tests FAILED
test failed test_socketThe editor requires the other tools to work: engine, bob, docs etc.
So one must build those things in order.
If you build with running tests, the build will stop if any errors occur.
There might be some issue with that test on Windows, so you can try to build without building+running the tests:
$ ./scripts/build.py build_engine --platform=x86_64-win32 --skip-codesign --skip-docs --skip-bob-light --skip-tests -- --skip-build-tests
Thanks, it now completes without error. However, I’m unsure how to launch it. I tried opening the launcher at \tmp\dynamo_home\bin\x86_64-win32 both in explorer and via command prompt but nothing happens and it returns without any message in command prompt. Is there some way I’m meant to start the editor?
Thanks! I now have the editor opening 
@Mathias_Westerdahl helped me build the engine/editor here: Help building Defold? and I have now swapped out the mobdebug.lua file to version 0.709. However, the error still presents. I tested debugging some known debuggable code and couldn’t tell any difference. I assume the editor is using the mobdebug.lua at /tmp/dynamo_home/content/builtins/scripts
No, I think it is using https://github.com/defold/defold/tree/dev/editor/bundle-resources/_defold/debugger
I now have a modified version of the mobdebug.lua code working in my Defold build. However, I had to diff the module with the existing and perform some similar commenting outs, and replace the socket require to use the builtin one. Also, I noticed that the newer version is using a newer dependency for “serpent.” I investigated the changes for mobdebug and it seems this could be perhaps the cause:
I’ll see if I can update serpent as well and see if it fixes the issue.
EDIT: Nevermind, the mobdebug.lua file embeds the updated serpent module internally, it doesn’t require an external dependency. That doesn’t fix the issue in this case though. I have print statements to verify I’m loading the modified mobdebug.lua code. It does still work seemingly for the areas of the code which were previously debuggable. I can send over the updated module if you want. Also I checked the terminal and no error is printed when the breakpoint fails to highlight in the editor.
I recently rebuilt the engine from source again to update and resolve an issue I created when messing around with LuaJIT :blush. I’ve noticed that Windows doesn’t properly migrate the engine for the editor when you use --platform=win32, only with --platform=x86_64-win32. Otherwise you have to copy the engine into that directory in the tmp/unpack/x86_64-win32 directory manually. Just thought I’d let you guys know in case you want to update the build docs
The editor only runs on 64 bit platforms.
One last question for now 
I’m seeing a message in the console repeatedly while running the built version of Defold:
[28]: java.base/java.lang.Thread.run(Thread.java:834)
GLDebugEvent[ id 0x20052
type Warning: implementation dependent performance
severity Medium: Severe performance/deprecation/other warnings
source GL API
msg Pixel-path performance warning: Pixel transfer is synchronized with 3D rendering.
when 1602349275784
source 4.6 (Compat profile, arb, debug, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 456.55 - hash 0x71ce496f]
Does this mean anything other than I’m running a custom build? If not, then is there some way to disable this since it’s hard to see if there are any actual errors happening since it shows up so many times.
Do you see this error immediately when you start the editor? Or does it appear after you’ve opened a .go or .collection for instance? You don’t get a stacktrace, right?
It happens every time I move the mouse over an editor window (go or collection.) There is a stack trace:
GLDebugEvent[ id 0x20052
type Warning: implementation dependent performance
severity Medium: Severe performance/deprecation/other warnings
source GL API
msg Pixel-path performance warning: Pixel transfer is synchronized with 3D rendering.
when 1602424407973
source 4.6 (Compat profile, arb, debug, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 456.55 - hash 0x4056da11]
[2]: jogamp.opengl.GLDebugMessageHandler$StdErrGLDebugListener.messageSent(GLDebugMessageHandler.java:347)
[3]: jogamp.opengl.GLDebugMessageHandler.sendMessage(GLDebugMessageHandler.java:332)
[4]: jogamp.opengl.GLDebugMessageHandler.glDebugMessageARB(GLDebugMessageHandler.java:358)
[5]: jogamp.opengl.windows.wgl.WGL.dispatch_wglMakeCurrent0(Native Method)
[6]: jogamp.opengl.windows.wgl.WGL.wglMakeCurrent(WGL.java:157)
[7]: jogamp.opengl.windows.wgl.WindowsWGLContext.wglReleaseContext(WindowsWGLContext.java:167)
[8]: jogamp.opengl.windows.wgl.WindowsWGLContext.releaseImpl(WindowsWGLContext.java:448)
[9]: jogamp.opengl.GLContextImpl.release(GLContextImpl.java:417)
[10]: jogamp.opengl.GLContextImpl.release(GLContextImpl.java:382)
[11]: editor.scene$update_image_view_BANG_$fn__61854.invoke(scene.clj:1156)
[12]: editor.scene$update_image_view_BANG_.invokeStatic(scene.clj:1155)
[13]: editor.scene$update_image_view_BANG_.invoke(scene.clj:1127)
[14]: editor.scene$refresh_scene_view_BANG_.invokeStatic(scene.clj:842)
[15]: editor.scene$refresh_scene_view_BANG_.invoke(scene.clj:827)
[16]: editor.app_view$refresh_scene_views_BANG_$fn__68909.invoke(app_view.clj:1367)
[17]: editor.app_view$refresh_scene_views_BANG_.invokeStatic(app_view.clj:1366)
[18]: editor.app_view$refresh_scene_views_BANG_.invoke(app_view.clj:1363)
[19]: editor.app_view$make_app_view$fn__68940.invoke(app_view.clj:1461)
[20]: editor.ui$__GT_timer$fn__19171$fn__19172.invoke(ui.clj:1923)
[21]: clojure.lang.AFn.run(AFn.java:22)
[22]: com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
[23]: java.base/java.security.AccessController.doPrivileged(Native Method)
[24]: com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
[25]: com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
[26]: com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
[27]: com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
[28]: java.base/java.lang.Thread.run(Thread.java:834)