If you're testing a binary, go install will overwrite the installed
version, which is usually not what you want. In that case, go build makes
sense.
-rob
On Thu, Jun 16, 2016 at 1:17 AM, Dave Cheney wrote:
> I don't understand why that flag even exists, if feels like a symptomatic
> misfeature
I don't understand why that flag even exists, if feels like a symptomatic
misfeature. Just use go install -v, always*
* except when cross compiling.
> On 16 Jun 2016, at 18:11, Harmen B wrote:
>
> Or build with `go build -i`
>
>> On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson
>> wrote:
>>
Or build with `go build -i`
On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson
wrote:
> He might be running go test which also seems to rebuild everything every
> time unless it has been installed.
>
> go test -i installs all the dependencies for a test and fixes this problem.
>
>
> On Wed, Jun 15,
This is why I recommend go install*
* There is only one place where go install is not appropriate, and
that is when cross compiling **
** when using version of Go distributed as a binary and installed in a
directory that you don't have permission to write to.
On Thu, Jun 16, 2016 at 9:52 AM, Hug
He might be running go test which also seems to rebuild everything every
time unless it has been installed.
go test -i installs all the dependencies for a test and fixes this problem.
On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney wrote:
> My guess is you are using go build, which compiles then
My guess is you are using go build, which compiles then discards everything it
just compiled (unless what was compiled was a main package, in which case the
binary will be left in your current working directory)
I recommend using go install -v rather than go build for general use.
--
You rece
If you run `go install github.com/mattn/go-sqlite3/...` it'll cache that
build step artifact.
John Weldon
m) 503-941-0825
On Wed, Jun 15, 2016 at 3:42 PM, Alex Flint wrote:
> Hmm but I am also not changing the Go source of the package in question,
> yet the C sources seem to get recompiled.
>
Hmm but I am also not changing the Go source of the package in question,
yet the C sources seem to get recompiled.
Just to make sure we're on the same page, I have two packages: mypkg and
go-sqlite3, where the former is pure Go and the depends on the latter,
which contains both C and Go code. When
If your cgo code is in another package to the one your are changing then
compilation should be cached?
Are you using go build or go install?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving email
On Wed, Jun 15, 2016 at 2:54 PM, Alex Flint wrote:
> Under what conditions does a cgo package get recompiled? I am using
> go-sqlite3 and it appears that the C compiler/linker is run every time I
> build my project, even though I am not changing any of the C sources. I
> would have expected it to
Under what conditions does a cgo package get recompiled? I am using
go-sqlite3 and it appears that the C compiler/linker is run every time I
build my project, even though I am not changing any of the C sources. I
would have expected it to be run once and then the results re-used, but
perhaps there
11 matches
Mail list logo
