Re: Using (recursive #t) in (origin git-reference)

["(" <paren@disroot.org>]

Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org> writes:
> Is there a trick to fetching Git submodules with (recursive? #t)? It
> does not seem to work with the package definition below.
>
> The code uses Ekaitz's proposed Zig build system. [1] Thank you!

Not sure whether or not you've already done this, but when you're doing
``(recursive? #t)'' the hash will be for the source code with submodules
checked out, so you need to fetch them all in your ``git clone'' before
doing ``guix hash -rx .''.

(If you've already tried building it without the RECURSIVE?, then this
issue will go unnoticed, as the derivation paths for these two objects:

  (origin
    (method git-fetch)
    (uri (git-reference
          (url "…")
          (commit (string-append "v" version))))
    …)

  (origin
    (method git-fetch)
    (uri (git-reference
          (url "…")
          (commit (string-append "v" version))
          (recursive? #t)))
    …)

are *exactly the same*, as the output path is the hash, followed by a
dash, followed by whatever's given in FILE-NAME.  Thus, they are treated
as exactly the same object, making rebuilding pointless in Guix's eyes,
because you've already got that "same" output in your store from the
first build without RECURSIVE?.

This is also, funnily enough, why it's not a great idea to first copy
another origin's hash, then try to build, in the hopes of getting the
actual hash from the "expected hash: …" message; if you haven't changed
the FILE-NAME, or haven't included one, the output path will be exactly
the same as the original package's, meaning that one will be used as the
source if you happen to have it in your store! [IIUC, of course.])

That being said, you may know all this and have already taken it into
account, in which case I'm not sure what's going on here :)

  -- (