How to exclude code from compilation?

<p>I&#39;ve seen a few articles and read through the <code>go build</code> documentation but I&#39;m not quite clear on how to exclude files from a build. </p> <p>Here are my use cases:</p> <ul> <li><p>Don&#39;t include <code>_test.go</code> files. I&#39;m having a hard time finding if this happens by default or not.</p></li> <li><p>How to exclude a testutil package from being used outside of a projects repo and no included in build. (I&#39;m thinking this would would be an <code>internal</code> package but having hard time finding an official Go article on it)</p></li> <li><p>Have a main package that only gets used to run a library within it&#39;s own repo, but is not useable outside of the library repo and not included in a build (I think this is also the <code>internal</code> package but I could be wrong)</p></li> </ul> <hr/>**评论：**<br/><br/>natefinch: <pre><p>The docs are in a completely unintuitive place (IMO), so here&#39;s a link: <a href="https://golang.org/pkg/go/build/#hdr-Build_Constraints" rel="nofollow">https://golang.org/pkg/go/build/#hdr-Build_Constraints</a></p></pre>natefinch: <pre><p>Gah, I should read more closely before I respond. The above won&#39;t actually help.</p> <p>So, for _test.go files, they&#39;re only compiled when you&#39;re running tests, so no worries there, it Just Works. </p> <p>For internal packages.... this is the best link I could find, which is pretty bad, IMO: <a href="https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit" rel="nofollow">https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit</a></p> <p>The long and the short of internal packages is that nothing outside your repo can import anything in there. Also nothing outside the directory tree of the internal package can import it, even from the same repo.</p> <p>So like foo/bar/internal/baz - baz can be imported by anything under foo/bar (.e.g foo/bar/xyz), but not by anything outside of bar, so foo/abc would not be able to import baz.</p> <p>The main package that&#39;s only used to run a library... it won&#39;t get included in builds of anything that doesn&#39;t import it. However, there&#39;s no way to stop someone from downloading the code and running go build in that directory, either.... but that shouldn&#39;t matter. If you just state that it&#39;s an internal utility and not meant for public consumption... people will ignore you or not, but if it breaks, you can point to your warning as to why you&#39;re not going to fix it for them</p></pre>shovelpost: <pre><p>You might want to use build tags.</p> <p>Guard the files you want to exclude with <code>// +build test</code>. The word <code>test</code> can be anything. Those files will be excluded when you do <code>go build</code>. If you want to include them you have to do <code>go build -tags=test</code>.</p></pre>Destructicorn: <pre><p>Cool, I&#39;ll take a look into those thanks!</p></pre>zak10: <pre><p><code>*_test.go</code> files are not included in the binary <a href="https://stackoverflow.com/questions/44685206/will-go-test-code-only-referenced-in-test-files-be-complied-into-the-binary" rel="nofollow">[1]</a>.</p> <p>Furthermore, only code that is able to be reached by your main package will be compiled. So in your case, if your <code>testutil</code> package is only used by your <code>*_test.go</code> files, they will <em>not</em> be compiled.</p> <p>As for your third point, I don&#39;t know if I&#39;ve ever seen that so not quite sure of the answer.</p></pre>Destructicorn: <pre><p>Oh that&#39;s awesome I didn&#39;t know Go optimized by only compiling reachable code. I&#39;ve finally got a handle on actually coding the language but still learning all the optimizations and processes that happen when compile and running Go code.</p></pre>titpetric: <pre><p>I haven&#39;t seen internal packages in the wild until now, but they are used only from $GOHOME so that seems to satisfy both 2) and 3). Generally <code>main</code> isn&#39;t exportable unless you&#39;re writing a plugin for a .so build (afaik).</p> <p>That being said, it&#39;s common practice to have projects like this:</p> <pre><code>example -- `package example` (+ tests) example/cmd/something/ -- `package main` </code></pre> <p>As understood, the cmd (main package) can import <code>example</code> and <code>example/internal</code>, but it couldn&#39;t import something that&#39;s internal and vendored (ex: <code>github.com/user/project/internal/xxxx</code>). If it works. Technically relative imports should work too, <a href="https://github.com/golang/go/issues/15478" rel="nofollow">but there are outstanding issues with vendored package use</a>. Milage with <code>internal/</code> might vary here, but without some tests I can&#39;t be sure. Technically <code>vendor</code> is in GOHOME so...</p> <p>Edit: let&#39;s just call this TL:DR don&#39;t use internal/</p></pre>