GNU bug report logs - #47539
[PATCH 00/28] Add gh and dependencies

Previous Next

Full log

Message #320 received at 47539 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Xinglu Chen <public <at> yoctocell.xyz>
Cc: 47539 <at> debbugs.gnu.org, Leo Prikler <leo.prikler <at> student.tugraz.at>
Subject: Re: [bug#47539]
Date: Mon, 7 Jun 2021 13:19:07 -0400

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 :)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.