> On May 12, 2020, at 4:06 PM, Nick Rosbrook <rosbro...@gmail.com> wrote: > > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments > unless you have verified the sender and know the content is safe. > > On Tue, May 12, 2020 at 10:36 AM George Dunlap <george.dun...@citrix.com> > wrote: >> >> >> >>> On Apr 30, 2020, at 10:39 PM, Nick Rosbrook <rosbro...@gmail.com> wrote: >>> >>> Initialize the xenlight Go module using the xenbits git-http URL, >>> xenbits.xen.org/git-http/xen.git/tools/golang/xenlight, and update the >>> XEN_GOCODE_URL variable in tools/Rules.mk accordingly. >>> >>> Signed-off-by: Nick Rosbrook <rosbro...@ainfosec.com> >>> --- >>> tools/Rules.mk | 2 +- >>> tools/golang/xenlight/go.mod | 1 + >>> 2 files changed, 2 insertions(+), 1 deletion(-) >>> create mode 100644 tools/golang/xenlight/go.mod >>> >>> diff --git a/tools/Rules.mk b/tools/Rules.mk >>> index 5b8cf748ad..ca33cc7b31 100644 >>> --- a/tools/Rules.mk >>> +++ b/tools/Rules.mk >>> @@ -36,7 +36,7 @@ debug ?= y >>> debug_symbols ?= $(debug) >>> >>> XEN_GOPATH = $(XEN_ROOT)/tools/golang >>> -XEN_GOCODE_URL = golang.xenproject.org >>> +XEN_GOCODE_URL = xenbits.xen.org/git-http/xen.git/tools/golang >> >> The primary effect of this will be to install the code in >> $PREFIX/share/gocode/xenbits.xen.org/git-http/xen.git/tools/golang/xenlight >> when making debballs or doing `make install`. >> >> I don’t immediately see the advantage of that, particularly if we’re still >> thinking about having a “prettier” path at some point in the future. What >> was your thinking here? > > With the module being defined as `xenbits.xen.org/...`, the `build` > Make target will fail as-is for a module-aware version of go (because > it cannot find a module named `golang.xenproject.org/xenlight`). So, > the reason for this change is to preserve the existing functionality > of that Make target. Changing XEN_GOCODE_URL seemed like the correct > change, but I'm open to suggestions.
Oh. But no, that’s not at all what we want. The whole point of running ‘go build’ is to make sure that *the code we just copied* — the code right now in our own local tree, perhaps which was just generated — actually compiles. It looks like when we add the `go.mod` further up the tree, it makes `go build` ignore the GOPATH environment variable we’re giving it, which causes the build failure. But your “fix” doesn’t make it use the in-tree go code again; instead it looks like it causes `go build` command to go and fetch the most recent `master` version from xenbits, ignoring the go code in the tree completely. :-) -George
