Closed MainPoser closed 4 weeks ago
What I expected was to recursively search for dependencies under the vendor in the path of the program I specified, but I mistakenly searched for dependencies in the real directory corresponding to the program path, resulting in the failure to find the corresponding dependencies.
I tried reading the source code of the plugin and found a problem at extension/src/goDebugConfiguration.ts:495. Here it is forced to pass . to the dlv program. As a result, the dlv is not compiled and debugged based on the program parameters configured in launch.json. I manually changed . to the value of the original passed-in program variable, and I can compile and debug normally, but I don’t know if this modification is appropriate.
I don't understand why the passed in program value is not used here, but "." is forced to be used.
@MainPoser Can you build your binary from the program directory? (i.e. cd dirname
) using the "go build ." command. That is because in module mode (which is the default and used by most of Go and VS Code Go users), go build
must run inside a module and running from the main package directory is the easiest way to ensure the command is running inside the package's module. Since GOPATH mode is not actively maintained, I am reluctant to adjust this any further at this moment. A workaround would be to configure a task that builds your program as you wish and then configure it as a pretask of the exec
mode debugging launch configuration.
@hyangah okay, thank you. I know exactly what you want to express. For me, I directly modified this piece of code, not using ".", but using the passed in program. I think it is possible to set the compilation directory according to whether GOModule is turned on or not. This should be a way.
@MainPoser am I understanding correctly that you want VS Code to detect that there's a symlink in GOPATH pointing to your project? Did you open the GOPATH directory itself? If not, I don't think VS Code Go is ever going to build in the heuristics you describe, to look for symlinks in GOPATH. As @hyangah said, GOPATH mode is not actively maintained.
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
* Run `go version` to get version of Go from _the VS Code integrated terminal_. - go version go1.21.5 linux/amd64 * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - golang.org/x/tools/gopls (0.15.1) * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - 1.87.0 - 019f4d1419fbc8219a181fab78923bccf7ee29a2 - x64 * Check your installed extensions to get the version of the VS Code Go extension - 0.41.1 * Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > `Go: Locate Configured Go Tools` command. - ![image](https://github.com/golang/vscode-go/assets/48462313/eb294378-78ec-453b-844d-96e67d441bc9)>
Share the Go related settings you have added/edited
Run
Preferences: Open Settings (JSON)
command to open your settings.json file. Share all the settings with thego.
or["go"]
orgopls
prefixes.settings.json
launch.json
Describe the bug
After soft-linking projects in other directories to gopath and starting debugging, compilation fails and dependent packages cannot be found when an error is reported. The gopath mode is used, and the dependent packages are placed in the vendor directory under the parent directory of the soft link directory.
It is expected that compilation and debugging can be performed normally in the directory after soft connection. Instead of the real directory corresponding to the soft link
Steps to reproduce the behavior:
Screenshots or recordings
If applicable, add screenshots or recordings to help explain your problem.