There was an unfortunate misunderstanding in #180 which did not properly take account of how xgo.go handled remote builds as compared to local builds, and modules.
This PR adjusts the way xgo handles GO111MODULE and the way it sets GO111MODULE to more closely match the way go 1.16+ handles GO111MODULE - and it makes remote builds work again (albeit there is a problem here, see below...)
From go1.16 module aware builds are assumed by default with GO111MODULE. This means GO111MODULE="" means GO111MODULE="on". This differs from the previous state where GO111MODULE="" meant GO111MODULE="auto".
xgo will now respect the GO111MODULE environment variable in the context it run in. If it is empty, a module aware build is performed by default. If it is "auto"xgo will interrogate the repository to discover it should be "on" or "off" in a similar way to go. HOWEVER, "auto" is not supported for remote builds as source code is not available to it. (It would be possible to move some of this into the build.sh or make it a separate command if this was required.)
Next, when doing a module-aware build of a remote repository the bug in #180 has been fixed, and because of the change in go1.18 that causes go get to not work outside of a module by default - the go get command is explicitly run with GO111MODULE="off" to get the old GOPATH go get variant.
Potential issues:
GO111MODULE="auto" is not supported for remote builds - this could be made supportable as described above.
The hack above using GO111MODULE="off" to make go get work for remote builds is probably going to stop working within a few more releases of go.
There was an unfortunate misunderstanding in #180 which did not properly take account of how xgo.go handled remote builds as compared to local builds, and modules.
This PR adjusts the way
xgohandlesGO111MODULEand the way it setsGO111MODULEto more closely match the way go 1.16+ handlesGO111MODULE- and it makes remote builds work again (albeit there is a problem here, see below...)From go1.16 module aware builds are assumed by default with
GO111MODULE. This meansGO111MODULE=""meansGO111MODULE="on". This differs from the previous state whereGO111MODULE=""meantGO111MODULE="auto".xgowill now respect theGO111MODULEenvironment variable in the context it run in. If it is empty, a module aware build is performed by default. If it is"auto"xgowill interrogate the repository to discover it should be"on"or"off"in a similar way togo. HOWEVER,"auto"is not supported for remote builds as source code is not available to it. (It would be possible to move some of this into thebuild.shor make it a separate command if this was required.)Next, when doing a module-aware build of a remote repository the bug in #180 has been fixed, and because of the change in go1.18 that causes
go getto not work outside of a module by default - thego getcommand is explicitly run withGO111MODULE="off"to get the old GOPATHgo getvariant.Potential issues:
GO111MODULE="auto"is not supported for remote builds - this could be made supportable as described above.GO111MODULE="off"to makego getwork for remote builds is probably going to stop working within a few more releases of go.Fix #187
Signed-off-by: Andrew Thornton art27@cantab.net