New Go programmers often don't know or get confused what the fundamental go build command does.
What do exactly the go build and go install commands build and where do they put the result/output?
What the go command does depends on whether we run it for a "normal" package or for the special "main" package.
For packages
go build builds your package then discards the results.
go install builds then installs the package in your $GOPATH/pkg directory.
For commands (package main)
go build builds the command and leaves the result in the current working directory.
go install builds the command in a temporary directory then moves it to $GOPATH/bin.
What to pass to go build?
You may pass packages to go build, packages you want to build. You may also pass a list of .go files from a single directory, which is then treated as the list of source files specifying a single package.
If no packages (import paths) are provided, the build is applied on the current directory.
An import path may contain one or more "..." wildcards (in which case it is a pattern). ... can match any string, e.g. net/... matches the net package and packages being in any of its subfolders. The command
go build ./...
often used to build the package in the current folder and all packages recursing down. This command issued in a project root builds the complete project.
For more about specifying packages, run go help packages.
Regarding modules
Preliminary support for Go modules was introduced in Go 1.11, and modules became default starting with Go 1.13. When the go tool is run from a folder which contains a go.mod file (or one of the parents of the current folder), the go tool runs in module-aware mode (the legacy mode is called GOPATH mode).
In module-aware mode, GOPATH no longer defines the meaning of imports
during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
and installed commands (in GOPATH/bin, unless GOBIN is set).
When building modules, what is built is specified by the build list. The build list initially contains only the main module (the module containing the directory where the go command is run), and the dependencies of the main module are added to the build list, recursively (dependencies of dependencies are also added).
For more info, run go help modules.
Basically you can use go build as a check that the packages can be built (along with their dependencies) while go install also (permanently) installs the results in the proper folders of your $GOPATH.
go build will silently terminate if everything is OK, and will give you error messages if the packages cannot be built/compiled.
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
For a start, read the official How to Write Go Code page.
More information about the go tool: Command go
You can also get more help by running the following command:
go help build
It is also worth noting that starting with Go 1.5 go install also removes executables created by go build (source):
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind...
To complete the list, go run compiles your application into a temporary folder, and starts that executable binary. When the app exits, it properly cleans up the temporary files.
Question inspired by Dave Cheney's What does go build build?
For package:
go build: builds your package then discards the results
That won't be true after Go 1.10 (Q1 2018), thank to CL 68116 and CL 75473. See this thread, that I reference here.
What do exactly the go build and go install commands build
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
Actually... go install will change also with Go 1.10, in addition of the new cache:
The "go install" command no longer installs dependencies of the named packages (CL 75850).
If you run "go install foo", the only thing installed is foo.
Before, it varied. If dependencies were out-of-date, "go install" also installed any dependencies.
The implicit installation of dependencies during "go install" caused a lot of confusion and headaches for users, but it was previously necessary to enable incremental builds.
Not anymore.
We think that the new "install what I said" semantics will be much more understandable, especially since it's clear from bug reports that many users already expected them.
To force installation of dependencies during "go install", use the new "go install -i", by analogy with "go build -i" and "go test -i".
The fact that "go install" used to install any rebuilt dependencies caused confusion most often in conjunction with -a, which means "force rebuild of all dependencies".
Now, "go install -a myprog" will force a complete rebuild of all dependencies of myprog, as well as myprog itself, but only myprog will get installed. (All the rebuilt dependencies will still be saved in the build cache, of course.)
Making this case work more understandably is especially important in conjunction with the new content-based staleness analysis, because it sees good reasons to rebuild dependencies more often than before, which would have increased the amount of "why did my dependencies get installed" confusion.
For example, if you run "go install -gcflags=-N myprog", that installs a myprog built with no compiler optimizations, but it no longer also reinstalls the packages myprog uses from the standard library without compiler optimizations.
Related
Not having previous knowledge about creating a project from zero within terminal, I've created a folder, cd into of it then run go mod init my_project_name which created a go.mod file for me, then I've created main.go file which built just ok.
Then I created a folder and add a go file inside with package name (being same with directory) and create a struct inside of it. Next I tried to import that package in main package but when I try to build on terminal it gave me this error
go: cannot determine module path for source directory /Users/berkcan/workspace/go/my_project_name (outside GOPATH, module path must be specified)
After googling and not being able to find a solution to my problem, I've imported project to beloved Intellij IDE and I enabled Go modules integration then everything worked flawlessly. First I thought IDE doing some magic inside while building project but even when I try go build command in terminal, it built. But I cant see difference in project structure or a new line in go.mod file.
So what happened, what did Intellij IDE did when I ticked go module integration box and what I can do enable it on terminal without Intellij IDE ?
here is the photo of option in IDE when ticked
IntelliJ IDEA plus Go plugin or GoLand under the hood has two modes to get the information about your packages (simplified):
GOPATH. IDEA scans your $GOPATH directory to build internal indexes of your packages and provides code completion, resolving, etc.
Go Modules. IDEA executes go list -m -json to resolve your dependencies and scans your $GOPATH/pkg/mod directory (default value of GOMODCACHE) for the packages. If they don't exist, IDEA executes go mod download. After these operations, the IDE provides all built-in features like code completion, navigation and so on.
Both modes don't change your Go or environment variables as well as behavior in the terminal. When you check Enable Go Modules integration option in the settings, the IDE just switches the mode from scan $GOPATH to execute go list and resolve your dependencies from the Go Modules cache.
To summarize, IntelliJ IDEA doesn't do any magic. I suppose it relates to your custom Go environment variables inside the terminal, especially GO111MODULE and if you didn't pass these variables to the GUI apps (e.g. you have specified it in .zshrc file and run the IDE via Desktop entry instead of the terminal), IntelliJ IDEA doesn't inherit them. You can compare go env output inside your local terminal and built-in inside the IDE (View | Tool Windows | Terminal) and find differences.
New Go programmers often don't know or get confused what the fundamental go build command does.
What do exactly the go build and go install commands build and where do they put the result/output?
What the go command does depends on whether we run it for a "normal" package or for the special "main" package.
For packages
go build builds your package then discards the results.
go install builds then installs the package in your $GOPATH/pkg directory.
For commands (package main)
go build builds the command and leaves the result in the current working directory.
go install builds the command in a temporary directory then moves it to $GOPATH/bin.
What to pass to go build?
You may pass packages to go build, packages you want to build. You may also pass a list of .go files from a single directory, which is then treated as the list of source files specifying a single package.
If no packages (import paths) are provided, the build is applied on the current directory.
An import path may contain one or more "..." wildcards (in which case it is a pattern). ... can match any string, e.g. net/... matches the net package and packages being in any of its subfolders. The command
go build ./...
often used to build the package in the current folder and all packages recursing down. This command issued in a project root builds the complete project.
For more about specifying packages, run go help packages.
Regarding modules
Preliminary support for Go modules was introduced in Go 1.11, and modules became default starting with Go 1.13. When the go tool is run from a folder which contains a go.mod file (or one of the parents of the current folder), the go tool runs in module-aware mode (the legacy mode is called GOPATH mode).
In module-aware mode, GOPATH no longer defines the meaning of imports
during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
and installed commands (in GOPATH/bin, unless GOBIN is set).
When building modules, what is built is specified by the build list. The build list initially contains only the main module (the module containing the directory where the go command is run), and the dependencies of the main module are added to the build list, recursively (dependencies of dependencies are also added).
For more info, run go help modules.
Basically you can use go build as a check that the packages can be built (along with their dependencies) while go install also (permanently) installs the results in the proper folders of your $GOPATH.
go build will silently terminate if everything is OK, and will give you error messages if the packages cannot be built/compiled.
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
For a start, read the official How to Write Go Code page.
More information about the go tool: Command go
You can also get more help by running the following command:
go help build
It is also worth noting that starting with Go 1.5 go install also removes executables created by go build (source):
If 'go install' (with no arguments, meaning the current directory)
succeeds, remove the executable written by 'go build', if present. This avoids leaving a stale binary behind...
To complete the list, go run compiles your application into a temporary folder, and starts that executable binary. When the app exits, it properly cleans up the temporary files.
Question inspired by Dave Cheney's What does go build build?
For package:
go build: builds your package then discards the results
That won't be true after Go 1.10 (Q1 2018), thank to CL 68116 and CL 75473. See this thread, that I reference here.
What do exactly the go build and go install commands build
Whenever the go tool installs a package or binary, it also installs whatever dependencies it has, so running go install will also install packages your program depends on (publicly available, "go gettable" packages), automatically.
Actually... go install will change also with Go 1.10, in addition of the new cache:
The "go install" command no longer installs dependencies of the named packages (CL 75850).
If you run "go install foo", the only thing installed is foo.
Before, it varied. If dependencies were out-of-date, "go install" also installed any dependencies.
The implicit installation of dependencies during "go install" caused a lot of confusion and headaches for users, but it was previously necessary to enable incremental builds.
Not anymore.
We think that the new "install what I said" semantics will be much more understandable, especially since it's clear from bug reports that many users already expected them.
To force installation of dependencies during "go install", use the new "go install -i", by analogy with "go build -i" and "go test -i".
The fact that "go install" used to install any rebuilt dependencies caused confusion most often in conjunction with -a, which means "force rebuild of all dependencies".
Now, "go install -a myprog" will force a complete rebuild of all dependencies of myprog, as well as myprog itself, but only myprog will get installed. (All the rebuilt dependencies will still be saved in the build cache, of course.)
Making this case work more understandably is especially important in conjunction with the new content-based staleness analysis, because it sees good reasons to rebuild dependencies more often than before, which would have increased the amount of "why did my dependencies get installed" confusion.
For example, if you run "go install -gcflags=-N myprog", that installs a myprog built with no compiler optimizations, but it no longer also reinstalls the packages myprog uses from the standard library without compiler optimizations.
I am trying to compile some open source libraries in MinGW+MSYS. During the configure phase, I kept seeing some 3rd party libraries are missing.
For now, my solution is to download the source of the missing libraries and follow the GNU build process to compile and install them into my MinGW environment.
Is there any package management system for MinGW+MSYS to install packages easily? Just like apt-get.
I tried the mingw-get for the missing package. But it reports the error below.
mingw-get is the (closest equivalent to apt-get) package manager for MinGW and MSYS. However, it can only manage packages which are actually available for MinGW and/or MSYS, (either because a MinGW developer has built and packaged them, or a member of the MinGW user community has contributed them).
Arbitrarily guessing what packages may be available, and even what their correct package names may be, is unlikely to be productive. Run mingw-get in its GUI mode, (if it's properly installed, just running mingw-get without arguments should start it in this mode), to see a list of packages which are actually available; if you don't see any likely candidates for what you are looking for, then it doesn't (yet) exist. In that case, you will need to either find a non-MinGW alternative build, or build it yourself, from source. (If you choose the latter option, and your build is successful, then you may wish to consider contributing it to MinGW.org).
This works for me as a "package manager".
Install MSYS2. It comes with a package manager called pacman.
After writing some scripts in Go I asked myself if there is any difference between the compilation of a .go-file and the later execution and the go run FILE.go command in terms of performence etc.
Are there any advantages if I start a webservice with one of these methods?
go run is just a shortcut for compiling then running in a single step. While it is useful for development you should generally build it and run the binary directly when using it in production.
'go install' command will create shared library compiled file as package.a under pkg folder and exec file under bin directory.
go run command is useful while doing development as it just compiles and run it for you but won't produce binaries in pkg folder and src folder
For DEV (local) environment - use go run,
For PROD environment - use go install this one better than go build because it installs packages and dependencies and you'll have Go toolchain.
I'm trying to install something with the following command:
make world
It takes a long time, and usually it ends up with an error saying that I'm missing some kind of package. I found out what the package is, install it, and run the thing again, only to find out after a long time that I'm missing another package. Is there a way to find out all the packages I need to install without having to go through this process?
This is generally what the configure script does. If the project you're building doesn't have one, you should write one.
The best way to deal with dependencies is with a package manager such as:
On Ubuntu: apt-get
On Red Hat / Fedora: yum
On Mac OS X: port
On Windows: cygwin
If you install software with a package manager, it will automatically fetch, download, and install any dependencies as necessary. These package managers support a huge number of popular open source projects, but not all projects are supported. Some of these package managers support creating custom package repositories, which allows them to be used for dependency management in-house, as well.
Unfortunately, there is no general way to get all the library dependencies of a Makefile (short of grepping for "lib", ".so", and "-l" which may give you spurious results); however, if you are installing an open source project, chances are that it is supported by a package manager on your system.