{uc-,}crux-llvm: Recommend cloning with --recurse-submodules

[langston-barrett]

See commentary on #888. Also, --recursive is no longer part of the git clone manpage, so replace with --recurse-submodules.

[RyanGlScott]

We should also update the quick start section of the README, since that is where the confusion in #888 arose.

[langston-barrett]

We should also update the quick start section of the README, since that is where the confusion in #888 arose.

@RyanGlScott This PR is intended to address the dicussion following this comment, which results from not having cloned the submodules (whereas the OP's issue was an actual build failure in crucible-go/golang). The quickstart section of the README already recommends cloning the submodules (via scripts/build-sandbox.sh), so I don't think a change is needed there.

[RyanGlScott]

Oh, my bad—I didn't realize that that was the purpose of the build-sandbox.sh script. (In my defense, that name is a bit misleading now that it's using v2-style cabal commands rather than sandboxes, but I digress.) Perhaps we should also update this line to use --recurse-submodules as well?

crucible/scripts/build-sandbox.sh

Line 3 in 7501d6b

git submodule update --init --recursive

Other than that, LGTM.

[langston-barrett]

Perhaps we should also update this line to use --recurse-submodules as well?

Ah, it's an either-or thing. You can either git clone --recurse-submodules, which clones and then fetches submodules, or you can git clone http:https://foo.bar/whatever.git, cd whatever.git, git submodule update --init --recursive. Docs for --recurse-submodules:

       --recurse-submodules[=<pathspec>]
           After the clone is created, initialize and clone submodules within based on the provided
           pathspec. If no pathspec is provided, all submodules are initialized and cloned. [...]

           Submodules are initialized and cloned using their default settings. This is equivalent to
           running git submodule update --init --recursive <pathspec> immediately after the clone is
           finished. This option is ignored if the cloned repository does not have a
           worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or --mirror is given)

[RyanGlScott]

Tricky. I see why there are two differently named options now—thanks for teaching me something!

Also, the CI failures aren't your fault—there's a slight misstep in the way the CI signs binaries on forks. I've opened #1031 to track this.