| 1 |
On 9/16/19 11:26 AM, William Hubbs wrote: |
| 2 |
> On Mon, Sep 16, 2019 at 10:48:14AM -0700, Zac Medico wrote: |
| 3 |
>> On 9/16/19 7:17 AM, William Hubbs wrote: |
| 4 |
>>> +BDEPEND=">=dev-lang/go-1.12" |
| 5 |
>>> + |
| 6 |
>>> +# The following go flags should be used for all go builds. |
| 7 |
>>> +# -mod=vendor stopps downloading of dependencies from the internet. |
| 8 |
>>> +# -v prints the names of packages as they are compiled |
| 9 |
>>> +# -x prints commands as they are executed |
| 10 |
>>> +export GOFLAGS="-mod=vendor -v -x" |
| 11 |
>> |
| 12 |
>> My experience with g-1.12.x was that you have to export GO111MODULE=on |
| 13 |
>> or else GOFLAGS="-mod=vendor" triggers an error like this: |
| 14 |
>> |
| 15 |
>> build flag -mod=vendor only valid when using modules |
| 16 |
> |
| 17 |
> I thought that was only if ${S} was in GOPATH, but I'll take a look real |
| 18 |
> quick. If it is, would it be best to bump the BDEPEND or turn on the |
| 19 |
> environment setting? |
| 20 |
|
| 21 |
I've tested again, and in fact it appears that GOPATH="${S}" triggers |
| 22 |
this error, so I guess it would be sufficient to ensure that GOPATH is |
| 23 |
unset. Maybe it's cleaner to explicitly export GO111MODULE=on though. |
| 24 |
-- |
| 25 |
Thanks, |
| 26 |
Zac |
Archives