go: Why do I need the pkg directory if I cannot delete the source files in src?

2
votes

I wrote a function (not! main) and prompted go install. This command generated a path and a package in my pkg-directory. I tested the function by using it in a main function, generated the .exe and everything worked just fine. After that, I wanted to see if I understood the concept of packages in go correctly and deleted the source file of the function in the src-directory and deleted the main .exe. I did not remove the package file in my pkg-directory. Then I tried to go install the main .exe again, but it didn't work: "package can not be found". I obviously missunderstood the whole concept because I thought I could use the packages in pkg without the source files in src. If my conclusion was correct, why do I need the "pkg" directory at all?

For more explanation take a look at this picture please:

In /bin is the binary code of the main function "hello". This main function also contains the function "reverse" of the "stringutil" package.

By generating the "hello.exe", Go also generates the package "stringutil" into pkg.

My question is: Should I not be able to delete "reverse.go" in src and still be able to use the same function because it was already put into pkg?

Is it just the way the AST works now that they've rewritten the compiler in go? It checks for GOPATH/src/**/.go when it parses the "imports", then when the linker goes to build the final binary, it'll go check pkg. So the compiler errors out first when trying to feed the ast to the assembler because of the incomplete source tree.

Thank you very much!!!

2
go
Of course you can delete the source files and use just the .a files in pkg: All you have to do is invoke the Go compiler and linker by hand, that is not via the go tool. What you encountered is how the go tool works and has nothing to do with Go as a language or "how packages work". - Volker

2 Answers

2
votes

It is true that the pkg dir is usually used as a cache directory, but also It is possible to use packages without having the source code available, with a feature named binary only packages AFAIK It was implemented since Go 1.7. However, there's a caveat for this approach: Versions of the compiler used to build the package and the compiler to 'use' the package to generate a new library/executable must match. Also, the files must match the pair of os/architecture to build against. If you want cross-compiling, you'll need to distribute your package to every pair of os/architecture you'll want to build.

This project has a demo for the aforementioned feature.

I hope my explanation was detailed enough :)

0
votes

The pkg dir is just a local cache for compiling, it's not something you can depend upon and it doesn't replace .go files, it's not a static lib dir but a temp build products dir. It speeds up compilation, so you don't need the pkg dir, but compiles might be slower if it is empty, and it is for the compiler's use, not yours.

As you've discovered, you do need the src dir.

To link a static library to your project, you could copy out that .a file and use ldflags to link but then you lose all the nice things like cross-compiling and having the entire source for your app, so unlike c for example people don't typically do that.