Re: [PATCH 2/3] golang/xenlight: init xenlight go module

[George Dunlap <George.Dunlap@citrix.com>]

> On May 12, 2020, at 4:06 PM, Nick Rosbrook <rosbrookn@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.Dunlap@citrix.com> wrote:
>> 
>> 
>> 
>>> On Apr 30, 2020, at 10:39 PM, Nick Rosbrook <rosbrookn@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 <rosbrookn@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