search

4kux / winsvc

Automatically exported from code.google.com/p/winsvc
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

tests fail on non-Windows #3

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Running `go test` on a non-Windows machine fails due to missing syscalls. 
Adding "// +build windows" before the package declaration in your two _test.go 
files disables these tests on such machines.

Original issue reported on code.google.com by matt.jib...@gmail.com on 3 Apr 2014 at 7:07

GoogleCodeExporter commented 8 years ago 
And why would you be running `go test` for this project on non-Windows? I 
don't, I cannot think of a setup when I would. Please, explain. Thank you.

Alex

Original comment by alex.bra...@gmail.com on 3 Apr 2014 at 10:58

GoogleCodeExporter commented 8 years ago 
According to the faq (http://golang.org/doc/faq#get_version), the approach 
Google uses when depending on a third party package is to copy that package 
into the current package and change your import paths to match. I recently did 
this on a project that uses winsvc and everything compiled and ran fine. 
However, as part of our build step we run "go test ./..." on the project root 
directory. This has the side effect of also testing all packages in our new 
third_party directory. winsvc failed its tests since it was not running on 
Windows.

I understand if you consider this a rare condition and wish to not change your 
code. But consider that it's Windows-only code with no limitation anywhere 
preventing go test from succeeding on any other architecture.

Original comment by matt.jib...@gmail.com on 3 Apr 2014 at 11:05

GoogleCodeExporter commented 8 years ago 
Thank you for the explanation. Let me sleep on it. :-)

Alex

Original comment by alex.bra...@gmail.com on 3 Apr 2014 at 11:10

GoogleCodeExporter commented 8 years ago 
I don't see problem renaming test files. Please review that change here 
https://codereview.appspot.com/84700046/. Thank you.

But this https://codereview.appspot.com/84300043/ will break your setup again.

Alex

Original comment by alex.bra...@gmail.com on 6 Apr 2014 at 2:16

GoogleCodeExporter commented 8 years ago 
Yes, that winsvc change would fix my setup. And, yes, that second cmd/go change 
looks like it would break it again. If that is the case, why not put build tags 
or rename all files, not just test files, to _windows.go?

Original comment by matt.jib...@gmail.com on 6 Apr 2014 at 5:03

GoogleCodeExporter commented 8 years ago 
> ... If that is the case, why not put build tags or rename all files, not just 
test files, to _windows.go?

Then godoc command on non-windows (and also godoc.org) will display no 
documentation for the package. Do you think it is OK?

Alex

Original comment by alex.bra...@gmail.com on 7 Apr 2014 at 3:03

GoogleCodeExporter commented 8 years ago 
That is a good point. But I still think it's better than the alternative of not 
being able to build/test. If I'm doing development of windows-only code, I'm 
doing it in windows, and so have a local godoc running there.

Original comment by matt.jib...@gmail.com on 7 Apr 2014 at 3:09

GoogleCodeExporter commented 8 years ago 
Sure, lets do this https://codereview.appspot.com/84360044 instead.

Alex

Original comment by alex.bra...@gmail.com on 7 Apr 2014 at 5:14

GoogleCodeExporter commented 8 years ago 
This issue was closed by revision 4264d55af70f.

Original comment by alex.bra...@gmail.com on 7 Apr 2014 at 6:44