Attila Lendvai schreef op do 28-04-2022 om 12:14 [+0000]:
> i'm afraid i'm stepping beyond my level of knowledge here... but i
> think this may not be true for golang.

Barring any evidence to the contrary, I'm going to assume this is not
the case, because this tends to be false for other languages.  And even
if the dependent does build while the dependency doesn't, then either
that would cause problems at runtime due to the dependency being broken
or the dependency is unused, i.e., it wasn't an actual dependency after
all.

Attila Lendvai schreef op do 28-04-2022 om 12:14 [+0000]:
> and AFAIU, the current GO-BUILD-SYSTEM doesn't reuse any build
> artifacts.

Currently, it doesn't reuse them, but in the past it did, and maybe in
the future it can do again.

More generally, the use of #:skip-build? and ‘let's only actually build
all the things in the leaf package’ has lead to several problems in
Rust:

  * things that weren't actually dependencies were packaged
    E.g.: all crates that require an unstable rust compiler.

  * things that are only required on platforms that Guix doesn't
    support anyways were packaged (e.g.: winapi, redox, cocoa and
    foundation crates
    (e.g.: crates using ‘unstable’ features which cannot be compiled,
    or crates

  * cycles (doesn't apply to Go though)

  * packages with incorrect dependency information, that only happen
    to work because of how #:skip-build? implies propagation and
    because of Cargo's dependency resolving algorithms smoothing over
    them (don't know if this applies to Go).

  * impossibility of grafting (not relevant to Go, I think Go is too
    static-library-specific for that?)

While maybe not all are 100% caused by #:skip-build? or apply to Go
100%, I don't think these issues should be spread to Go as well, so
TBC, ¬LGTM.

(I guess this invalid my previous remark:

> To be clear, my comment was more about the wording (feature / work-
> around / ...) than about the addition of #:skip-build?.

).

Greetings,
Maxime.