How to disable recompiling go source on debug?

Hello,

 

when clicking on the debug button, the project gets *always* compiled again before the debugger actually starts. Even though there are no changes. Is there a way to disable this behavior? It can get a little bit time consuming when working with projects that have many lines of code.

 

Best regards

0
8 comments
Official comment

There are build differences between a normal run and a debug build. In the debug build, the binary has all optimizations turned off so that it can improve the debugging experience.

However, if you still wish to attach to an existing binary that currently is running on your machine, you can use the "Run | Attach to local process..." feature to attach to a running Go process from your machine. As I said, the debugging experience will not be good in most cases if you use this feature.

Hi Florian,

Thanks for your reply!

Yes, as I've described in https://youtrack.jetbrains.com/issue/GO-4704#focus=streamItem-27-4134085.0-0 , when invoking "go build ..." command directly the build is lightning-fast while when launching a run/debug session in Goland it can be seen that go is always performing the linking step. This happens because, for unknown reasons, Goland writes four bytes to the output binary (hexa 7f 45 4c 46 which translates to "<non_printable_char>ELF" string), even on Windows, before invoking the "go build ..." command. Of-course, under these circumstances, the go compiler "will see" that it has to rebuild the binary.

For more info the issue comment can be checked (the link from above), where, after adding "-x -v" to the go tool, the build output can be seen when invoked by Goland and when invoked directly. Also, there is a snippet from a capture with "winproc.exe" on Windows where it can be seen that goland64.exe writes four bytes to the output binary, closes it and then launches the "go build ...".

 

Meanwhile, out of curiosity, I've "hacked" a bit the go tool, on Linux and now it works as expected (no linking process anymore when sources are up-to-date ) when launched from Goland. Through a small bash wrapper script, the "go build" is copying the output binary, after the build, to a second location and restore it at the next "go build ..." invocation (basically it overwrites the four bytes with the binary restored from the second location).

What can I do to further assist you with reproducing this behavior?

1

Okay, thank you.

0

Still, sometimes it's useful just to restart the debug session, without changing anything. Those few extra seconds required for the rebuild get annoying. Is there any workaround for having build and debug launch sessions as distinct steps?

As an workarround, using external tools (and attaching a shortcut to it) the build step can be achieved? How about lauching a debug session without recompile?

0

I don't know if this topic is monitored but I think this is happening because Goland writes four bytes ("<unprintable_char>ELF") to the final executable before it launches the "go build ..." command. Of course, go will see that it has to rebuild.

I've added more details at an older similar issue, here: https://youtrack.jetbrains.com/issue/GO-4704#focus=streamItem-27-4134085.0-0 .

0

> I don't know if this topic is monitored

It is.

> but I think this is happening because Goland writes four bytes

GoLand doesn't do anything special. It invokes the compiler, and then it's off to it to handle the compilation.

You should be able to reproduce the same effect if yo invoke the compiler from the command line using the same commands that the IDE uses. Do you get the same results from the command line as you get from the IDE?

> I've added more details at an older similar issue,

Thank you for the investigation.

0

Oh yes, please fix this, it's soo annoying and time consuming. Just re-running or re-debugging without changing a single line always leads to Goland recompiling the whole project.

0

Dieter Guendisch Hello, I see you have already voted for the task GO-9354. You will be notified of the progress of this issue. Thanks for your contribution.

0

Please sign in to leave a comment.