[bug#47539]

[Xinglu Chen]

On Sun, Jun 06 2021, Leo Famulari wrote:

> On Sat, Jun 05, 2021 at 09:16:36PM +0200, Xinglu Chen wrote:
>> On Fri, May 21 2021, Leo Famulari wrote:
>> > I notice that (most of?) the new packages use native-inputs for their
>> > dependencies.
>> >
>> > If these dependencies are used at run-time, I would propagate them
>> > instead. This way, they will be available in the build environment of
>> > packages that depend on the package that is using them, which matters
>> > for our go-build-system, where everything is built from scratch in each
>> > package. If I remember correctly, that is...
>> 
>> I am not familiar with the Go ecosystem, is there a way to tell if a
>> dependency is used at runtime?
>
> Remember, Go uses static compilation, so Guix's concept of "runtime"
> dependencies doesn't apply to Go like it does for other languages.
>
> For Go, you'll know that a dependency was missing, because the build
> will fail without it.

Everything built fine the last time I was working on this, and I was
able to open a GitHub issue using the resulting ‘gh’ binary, so things
seem to be OK.

> Our current go-build-system implementation rebuilds every dependency
> from source when it is used while building another package
> (inefficient!).

So kinda like what Cargo does?  Go doesn’t seem to have the concept of
shared libraries, I guess?

> If foo requires bar, and baz depends on foo, then bar needs to be
> available when building baz. That is because foo will be rebuilt while
> building baz.
>
> We must either propagate bar from foo, or make baz depend on it.
> Technically, bar is a dependency of foo, so it is correct to propagate
> it from foo.

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?

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

> You may also check if baz also depends on bar, by checking if baz tries
> to import bar. Go software imports (or declares?) its dependencies by
> importing them using "import paths" [0], as shown in this example:

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?

signature.asc
Description: PGP signature