I'd like to switch to using VSCode full time, but the one thing keeping me on IntellijIDEA is its ability to view Go standard and all dependency libraries in External Libraries of project which located in $GOROOT or $GOPATH/pkg/mod on the filesystem. In particular, I'd like it to work with Go. As of yet, I've been unable to find a suitable solution to view Go standard and all dependency libraries in the Explorer of VSCode.
You can do this with a few manual steps if you use Workspaces.
Once in a workspace (see link above if unfamiliar with the concept), you can use the GUI (Add folder to workspace) or, what I prefer, the integrated terminal (see example below).
From the integrated terminal:
$ code --add /path/to/"external library"
and the related library will appear in the explorer.
The added paths will be remembered by the workspace on vscode close and restart :-)
Try this plug-in "go mod explorer"
Related
Sometimes I really need to browse and check the code from external dependencies add to my go module.
Although I could CMD+click on the method and vscode editor opens the go file from external dependency, I would really like to see and quickly check other files from the package.
Goland allows this by showing module dependencies.
Is there any way to enable displaying module dependencies in visual studio code?
I'm not sure if this way is as quickly as you want, but after you cmd+Click and reached the external file you can do either of
Navigate all the file through navbar, this way you can check what version of the dependency and you can choose between different version that is available on your module directorey
2. Or you can Copy Path [Ctrl+K Ctrl+Alt+C on linux] then open terminal and do code <file-directory>. It opens a new vscode window on that directory so you can check all the files of the external dependencies.
I know it seems like a lot of step but once you get used to vscode shortcut(copy path, open terminal) i think it's the best we have right now :)
There is no such feature in the oficial Go extension for VS Code, or any extension that provides that as well.
However, there is an open issue https://github.com/golang/vscode-go/issues/2156 in the Go extension. It does not have too many votes (IMO), but it is assigned to a milestone that holds ideas that at least, are on the table to discussion.
Hope this helps
I would like to edit the Go standard library, so I can submit a pull request to the https://github.com/golang/go project.
I've checked out the source locally and I've opened the src subdirectory as a Goland project.
I run into issues because Goland is still using my local Go SDK (in /usr/local/go). This means when I edit files that use an internal package, I get errors in the editor. Goland is first looking in my system SDK, before it considers the files in my project.
In the Goland preferences, I tried setting the GOROOT to point at my checked out code (in my case, ~/git/go), but Goland complains "The selected directory is not a valid home for Go SDK".
I also tried setting GOROOT to "<No SDK>", but then Goland failed to resolve any types at all. Red error lines everywhere.
Any suggestions for how to hack on the Go standard library in Goland without errors?
I downloaded latest Gogland in order to run/debug Go 1.8.1 applications.
I have the exact problem in Latest Intellij Ultimate EAP.
my project's main package contains several files, when I try to run/debug it as a Go Application, it acts as a Go Single File.
which means that when I try to run the application while choosing the main go file, it complains about missing variables definitions from other files on that same directory that are in the main package as well.
in the Run Configuration when I choose Package instead of File, I can't choose the main package.
so how do I run/debug my project properly ?
thanks! :)
I've created the following video https://youtu.be/ko-wKntCLjg to better demonstrate how to achieve this.
There are two options that are also shows in the video:
the click on the link for adding the ldflags parameter: this is needed for Windows applications in order to allow them to be debugged as well as sometimes in CGO apps (or on OSX) for the same purposes. This is an issue with Go, not the IDE or the the debugger
the second option is the one that says Single instance only. I prefer my run configurations as such since they allow me to run them a single time and press the same shortcut to restart them when needed.
Depending on your operating system or application type, the first one might be needed, while the second one is purely functional for various use-cases (and as I've said, personal preference).
Hope this helps.
I created a Netbeans CPP Project in my Mac and uploaded it into git. The project has collaborators who use Windows.
When I pushed my project into github , I pushed the makefile information too (the whole project). Now the collaborators are getting build errors because the reference contains my Mac filepaths.
The Windows machine have cygwin installed.
How do I resolve it ?
How I do make it platform independent ?
What should I (and collaborators ) do to not affect the other workers ?
ANSWER : Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
Netbeans has an option (in the project properties under c++), to have the file path as absolute or relative. So I all had to do was, set the relative option and push the changes . The project started working for everyone ! VOILA !!!!!!!!
I've found that the project files generated by NetBeans for C++ are rather unweildy and aren't very maintainable by humans. And while they do tend to reference paths relatively from the root of the project (facilititating copying the project to different directories), there's just too many project files to maintain. And you're sol if they don't work.
I don't know if NetBeans allows you to specify environment variables for paths in the project settings dialogs. The macro/variable stuff is largely undocumented as far as I can tell. But if you know how to do that, then define all your file path dependencies by an environment variable instead of a hardcoded path in the project settings window. Remote developers need only redefine the environment vars on their machine.
But I think a better solution is to not use the NetBeans auto-generated Makefile from Project Settings. Instead, declare your own Makefile and create a NetBeans project type from "an existing Makefile". I've found that works really well.
Then you can have a line at the top of you Makefile as follows:
include common.inc
Where "common.inc" includes all the hardcoded library paths that are machine dependent. Here's an example of mine:
BOOST_INCLUDE := -I/home/jselbie/lib/boost_1_46_1
OPENSSL_INCLUDE := -I/home/jselbie/lib/openssl
And then my Makefile only references these directories by variable name. And so when I move the project around different machines with different configs, I just need to update common.inc.
And then if anyone else wants to use NetBeans to compile my project, they just need to create a NetBeans project from "an existing Makefile" option.
The option for relative file paths is actually NOT in the project properties! Instead, it's in the top menu bar.. choose "Tools" then "options" then click the "C/C++" tab, and the second box down is "File path mode" select "always relative"
We have a a product developed on Windows for years. The product is composed of one Eclipse workspace and about 20 projects.
On Windows, we ask every developer check out projects into d:\dev\product folder, and copy a unified Workspace to d:\dev\prod_workspace. This way, whenever a new machine is set, we simply copy files to the same folder, and we can start working immediately.
Now we need to move our development environment to Linux and Mac. But there's no D:\ on Unix. And home folder for Linux is mostly like /home/username and /Users/username for Mac. We found Eclipse keeps absolute path in workspace when referring to projects, so simply copy workspace over does not work anymore. Even when we manually create/configure workspace on a Linux machine, it still cannot be copied over to another user, because the absolute path is changed.
I guess our goal is to allow easy setup of development environment. Do you have any suggestion to move eclipse workspace around?
I develop an Eclipse based product for Mac and WIndows (haven't tried Linux).
The solution I found to work best is to actually go and manually check out the projects in the workspace on each machine directly from source control. While the project structure does convert between platforms, any attaches, such as version-control stuff does not. I am not sure why, but I guess each thing has its kinks.
You may be able to able to hasten things a little by creating a project working set (or whatever it's called, I think it's a PSF file) for a platform, and then reuse it on all platforms.
Another problem is that Eclipse versions are not 100% compatible. One of the problems I have is with manifest files for plugins, which have different semantics (e.g., what to do with exported packages that don't actually exist) in each platform, causing a headache.
Finally, be away that Java on Mac and PC are not identical. In fact, Eclipse has two versions for the Mac. I usually end up running and compiling on Java 5 on the mac, which does have some incompatibilities with Java 6.
I have ported my eclipse project from windows xp to RHEL(never tried Mac)
Your task can be accomplished in the following steps :-
Use workspace variables in your project code rather than absolute path.
Shift your workspace to some location in linux as /Workspace or if you want to keep it user specific make the workspace folder as /home/user_name/Workspace.
There is an option to change all the \ of windows to / in linux. The option can be found under the file menu in eclipse.
Change the settings of where to find classpath directories, the options can be found by just right clicking on the project menu in the project viewer panel.
There is an option to build the project clean from scratch. You just have to click on the option and eclipse would re-compile the project.
Once all this is done, and all your database connections have been successfully ported to linux, you would have a working project running in linux as well.
I can think of two ways to do this:
Use workspace variables in Eclipse to point to the exact location where the workspace sits, if you need that. Then the developer can put everything in the workspace on Windows, Unix, whatever, then define the variable and you're done, or
If compilation is always done from within Eclipse, meaning you don't truly need any absolute paths anywhere, then change the projects to all use relative paths and check the Eclipse classpaths, etc, into source control. Thus, when a developer checks out everything in Eclipse, the classpath and .project file will be at the root level in the project and all paths will be pre-defined.
For option #2, you may need to have multiple .project or .classpath files, and have the developer copy the appropriate one into location. That is, copy .classpath.win into .classpath for Eclipse's use.
If you check out the projects from a source repository, then consider using Team -> ProjectSets to handle these.
Preferences can be saved in a file and loaded.
We tried classpath variables and loathed them. Now we just have everything in single projects in the source repository.
Use the Workspace Preference Transferrer plugin
This allows you to transfer the workspace settings from a given workspace to another via new options in the 'switch workspaces' dialog.
I'll share my own solution:
Zip the workspace. Just zip the entire file and then transfer it over. Then, all you need to do is delete the default drive reference:D:\ ...or whatever ends up appearing in the beginning of your file name. Then all you need to do is drag it over to the new empty workspace on your newly downloaded Eclipse.