code review 85230043: go test: add -copybinary flag to redirect test binary

go test: add -copybinary flag to redirect test binary to outputdir.
Fixes issue 7724.

Closed in deference to CL 149070043.

[joefitzgerald, 2014-04-08 04:13:20]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[joefitzgerald, 2014-04-15 15:03:28]

Hi folks, this is a very simple change to `go test` to add a flag allowing the
test binary to be redirected (when using `-c`) to outputdir.

This is useful when you want to use `go test -c` to perform syntax checking of
source in an editor, and avoid having a `pkg.test` file show up: 

https://github.com/joefitzgerald/go-plus/issues/17

[bradfitz, 2014-04-15 15:50:57]

Sorry, this is 45 days past the code freeze for Go 1.3.  Please ping this
thread again after Jun 1st.



On Tue, Apr 15, 2014 at 8:03 AM, <joeyfitz@gmail.com> wrote:

> Hi folks, this is a very simple change to `go test` to add a flag
> allowing the test binary to be redirected (when using `-c`) to
> outputdir.
>
> This is useful when you want to use `go test -c` to perform syntax
> checking of source in an editor, and avoid having a `pkg.test` file show
> up:
>
> https://github.com/joefitzgerald/go-plus/issues/17
>
> https://codereview.appspot.com/85230043/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[rsc, 2014-04-17 02:33:40]

R=close

Please run 'hg mail' after the Go 1.3 release is out and it will reopen this CL
for us. Thanks.

[adg, 2014-08-22 04:00:52]

Let's look at this again

[adg, 2014-08-22 04:03:28]

I don't really like the name "-copybinary".

This is the equivalent of the -o flag taken by "go build". Maybe it should just
be -o ?

[joefitzgerald, 2014-08-22 14:04:57]

On 2014/08/22 04:03:28, adg wrote:
> I don't really like the name "-copybinary".
> 
> This is the equivalent of the -o flag taken by "go build". Maybe it should
just
> be -o ?

Functionally, yes it is the equivalent of the -o flag taken by go build. I was
worried about conflicting with -outputdir, but -o would be fine. I can make a
change to use that instead if you'd like.

[rsc, 2014-08-22 14:51:14]

not lgtm

I don't understand why we are doing this.
The initial issue (golang.org/issue/7724) says that it just wants to be able to
run something like 'go test' to compile the test code to check for syntax or
other errors, without running the tests. You can already do that by one of:

go test -c foo && rm foo.test
go test -run '^XXX' foo

[joefitzgerald, 2014-08-22 14:57:24]

On 2014/08/22 14:51:14, rsc wrote:
> not lgtm
> 
> I don't understand why we are doing this.
> The initial issue (golang.org/issue/7724) says that it just wants to be able
to
> run something like 'go test' to compile the test code to check for syntax or
> other errors, without running the tests. You can already do that by one of:
> 
> go test -c foo && rm foo.test
> go test -run '^XXX' foo

@rsc I am the author of the go-plus package for the Atom editor (please don't
hold it against me :)). I have syntax checking that is powered by go build and
go test - I essentially compile both sets of code and display any errors
reported by the tools to the users. This means:

* I am not running tests in this instance (I do for coverage)
* I do want to generate the foo.test file
* There is no way to prevent the foo.test file from being generated *in the
package folder*
* I can clean up the file from the package folder (as I do now), causing a brief
flicker in the user's window as the file shows up and disappears
* It would be desirable to be able to redirect foo.test to a temporary folder
which is not visible to the user (which is where there is functional equivalence
to go build -o)

[rsc, 2014-08-22 16:53:37]

joeyfitz,

    go test -run '^XXX'

will generate a test binary in a temporary directory and invoke it, but not
run any tests (tests must start with 'Test' or 'Example', so ^XXX cannot
match anything).

if you don't even want to invoke the test binary that much, you can run

    go test -c foo

from /tmp or some other temporary directory. go test -c writes to the
current directory, not the package directory.

russ

[joefitzgerald, 2014-08-22 18:00:31]

>     go test -run '^XXX'

This does achieve what I'm looking for, at the cost of additional complexity in
the regular expression I'm using to parse the output (no big deal). But if I
want to reuse the test binary, I cannot (shrug?).

>     go test -c foo

This also achieves what I'm looking for (i.e. set CWD to
var/folders/58/2j5xhr9n3zq4z8z_18tnh6z40000gn/T/somedir, run go test -c
github.com/someuser/somelibrary/somepackage), at the cost of needing to
determine the package path (i.e. github.com/someuser/somelibrary/somepackage)
which might be unreliable if the user is editing outside their GOPATH (which I
warn for anyway).

Thank you for providing this perspective - it's helpful in achieving the
functionality I want to provide to users.

I do wonder if it would also be useful to provide the -o flag to provide similar
functionality to that provided by go build, and make it a little easier for
people looking to redirect the test binary after running go test -c in a
package's directory. If it's just me that finds it useful, then it's probably
not worth putting in. What do you think?

[rsc, 2014-09-25 21:27:50]

Does CL 149070043 solve your problem?

[joefitzgerald, 2014-09-25 21:34:05]

On 2014/09/25 21:27:50, rsc wrote:
> Does CL 149070043 solve your problem?

Yes! Many thanks :)