[bug#47539]

[Leo Famulari <leo@famulari.name>]

On Mon, Jun 07, 2021 at 02:58:54PM +0200, Xinglu Chen wrote:
> So kinda like what Cargo does?  Go doesn’t seem to have the concept of
> shared libraries, I guess?

Apparently it has some concept of them, but it seems that it does static
compilation by default. This is touted as one of the strengths of Go: it
creates fully independent run-anywhere binaries.

> So if A dependes on B which depends on C, and I want to build A, then C
> has to be a ‘propagated-input’ for B?  Did I get that right?

Yes, for our go-build-system.

> But if I just want to build B, should C still be a ‘propagated-input’
> for B?

Yes, unless B is only an end-user executable, such as Syncthing. In that
case it doesn't matter if you use inputs or propagated-inputs.

> Right, but shouldn’t it be enough to just look at the content of the
> go.mod file, won’t it list all the dependencies of the package?

Yes, that should work too! But the module imports are the ultimate
"source of truth" in terms of what is used.

Sometimes you will find a Go program that has extraneous things in
go.mod. They are listed in go.mod but not actually imported anywhere,
and thus not used.

Also, I started learning about Go before Go modules were introduced, so
my admittedly weak knowledge is now even weaker. I only learned about Go
in order to do Guix packaging. If it sounds like I am wrong about
something, I probably am :)