Allow lowrisc_opentitan bazel module to be used as a non-root module by external workspaces.

[korran]

Example using this repo externally:
https://github.com/korran/opentitan-external-example

~/git/opentitan-external-example$ bazel build @lowrisc_opentitan//sw/host/opentitantool:opentitantool
<snip>
Target @@lowrisc_opentitan+//sw/host/opentitantool:opentitantool up-to-date:
  bazel-bin/external/lowrisc_opentitan+/sw/host/opentitantool/opentitantool
INFO: Elapsed time: 272.707s, Critical Path: 100.69s
INFO: 831 processes: 261 internal, 570 linux-sandbox.
INFO: Build completed successfully, 831 total actions

[a-will]

Thanks for contributing, Kor! This is a topic of interest these days, hehe.

You'll need to sign your git commits to get CI beyond the lint stage. (as in git commit --signoff, where it would append something like Signed-off-by: Kor Nielsen <user@domain> to the end of the commit message)

[jwnrt]

This looks good to me, I'm personally fine with merging the MODULE files if it lets us be used as a dependency. Thanks a lot.

Would you mind reformatting MODULE.bazel so that the sections are:

1. All bazel_deps at the top.
2. All overrides (git_override. and single_version_overrides).
3. The rest of the extensions and toolchain registrations.

You can also drop the "original from x.MODULE.bazel" comments if you like, they won't be useful anymore. Feel free to add "Rust configuration", "Python configuration" headers to separate the sections if you like though.

[pamaury]

Can you explain why this is necessary?

[korran]

I've found that when doing clean builds, intermittently bazel hasn't populated this directory before local_repository() is executed, and it fails with a file-not-found error.

FWIW, I don't think local_repository() should be abused to do what you want here, as it shouldn't be used to look at internal bazel-managed files (such as those in the lowrisc_opentitan module). I think it's much safer to to iterate over the files in this label and manually put them into the repo with rctx.file().

[korran]

I've changed this logic. Calling local_repository() on files from a label ends up putting horrible absolute paths into MODULE.bazel.lock, which is unacceptable. Instead, I've changed it to use a custom repository_rule that references the label instead of a path.

[korran]

Also, I wonder if this might be a lot simpler if instead of doing these environment-variable tricks, we just used a bazel module for these things, letting users override on the command line with --override_module=provisioning_exts=some/path.

[pamaury]

Hi Korran, this rule is there for mostly for pre-blzmod backward compatibility. We discussed switch to module overrides previously. Maybe we should accelerate the transition. @a-will @jwnrt

[jwnrt]

I know that somebody recently had issues with this being an extension since there was no way to add extra dependencies in the hook repo. I think making this an overridable module would solve that problem. Now would be a great time to do that.

[pamaury]

Thanks @korran for this contribution, this looks very useful. I don't know if we should make this part of this PR, but I think some kind of CI check to make sure that we do not regress would be very useful. Otherwise it's only a matter of time before we split another @//something instead of @lowrisc_opentitan// which will break the repo.

Ping @jwnrt @cfrantz on that.

[korran]

You'll need to sign your git commits to get CI beyond the lint stage. (as in git commit --signoff, where it would append something like Signed-off-by: Kor Nielsen <user@domain> to the end of the commit message)

I've added sign-offs to all the commits.