Question about go generate

<p>Does &#34;go generate&#34; do anything other than run the command passed as a parameter? It seems that you still need to write a program which generates the entire output file to do anything non-trivial, and if that&#39;s the case what&#39;s the benefit of go generate?</p> <p>For instance, I want to generate a valid Go file which contains byte arrays of the contents of files on the hard drive so that assets can be compiled into a binary. To do that, I seem to need to write a program which generates everything up to and including the &#34;// DO NOT EDIT&#34; line and the &#34;package $PACKAGENAME&#34; (which I need to make sure I pass as a parameter to my program..) and at that point I&#39;m not sure what benefit I get by using &#34;go generate&#34; to generate the code over just writing a simple shell script to run the program.</p> <p>(And as an aside: is there already a tool that does what I&#39;m trying to do? I don&#39;t want to reinvent the wheel if I don&#39;t have to..)</p> <hr/>**评论：**<br/><br/>daveddev: <pre><p>Regarding resource embedding: <a href="https://github.com/avelino/awesome-go#resource-embedding" rel="nofollow">https://github.com/avelino/awesome-go#resource-embedding</a></p></pre>driusan: <pre><p>Thanks! Any of those sound like exactly what I wanted to do and should save me a bunch of time!</p></pre>MrToolBelt: <pre><p>At work I&#39;m using go-bintool. It works great.</p></pre>daveddev: <pre><p>It, at the very least, helps to consolidate the build process.</p></pre>driusan: <pre><p>Except &#34;go build&#34; doesn&#39;t invoke &#34;go generate&#34; even if there&#39;s go:generate comments.. so as far as I can tell it&#39;s just a question of if you manually run &#34;go generate&#34;, &#34;./generate[.sh]&#34; or &#34;make generate&#34; before &#34;go build&#34;</p></pre>TheMerovius: <pre><p>Yes, it&#39;s just a question of if <em>everyone</em> manually runs &#34;go generate&#34;, &#34;./generate[.sh]&#34; or &#34;make generate&#34; before &#34;go build&#34; (btw: You are not supposed to run go generate before the build, but after a change to the generation process and then checkin the generated files. In the end, the code should be go-gettable and not need any external tools to be build).</p></pre>thockin: <pre><p>This is a great theory, but it&#39;s totally unrealistic in my experience. Any project of significant size either becomes polyglot (thus requiring non-language-specific tools) or accumulates build-related flags (thus requiring a layer above go build) or generates enough code that it becomes a nightmare to constantly rebase and merge against.</p> <p>Of all the things I grump about with Go, it&#39;s the intrusion into workflow that annoys me the most. The language should not dictate the tools. We already have a nearly universal interface to building projects - it is called &#34;make&#34;. Go should have just emitted makefile snippet.</p></pre>alaskacodes: <pre><p>I feel like the desire to be as free as possible from external dependencies is kind of crucial to go&#39;s identity, and has been from the beginning. I&#39;d venture to say that this is one of the reasons they pushed so hard to be self-hosting in 1.5.</p> <p>I shouldn&#39;t have to install MinGW/Cygwin/MSYS to get make so that I can build on Windows, much less any of the tools this process might depend on to get its job done.</p></pre>thockin: <pre><p>I get the desire, it&#39;s just hopelessly unrealistic. It&#39;s as naive as the initial vendoring/versioning non-solution - &#34;everyone should build from head of everyone else, and people will DTRT&#34;.</p> <p>LOL, nope.</p></pre>bkeroack: <pre><p>Make is horrifying.</p> <p>Should Go have a preprocessor as well?</p> <p>(edit: in fairness, I don&#39;t really see the point of &#34;go generate&#34; either...)</p></pre>thockin: <pre><p>You don&#39;t have to manually write Makefile to use make. As an API to users, make is beautiful and simple</p></pre>alaskacodes: <pre><p>I feel like it&#39;s worth mentioning here that <strong>go generate</strong> is more geared towards the developers/maintainers of a package. Unless it&#39;s your code, and you specifically know you need to call it, <strong>go generate</strong> isn&#39;t something you should need to run.</p></pre>TheMerovius: <pre><p>The benefit of go generate is, that you put the commands to be run into your source-code and people just have to run go generate and it goes out and finds all those commands to run and runs them (by the way, have you ever tried writing a portable shell-script? What a nightmare). It is the go way of &#34;we don&#39;t want meta-stuff in our repo&#34;.</p></pre>driusan: <pre><p>go generate doesn&#39;t do any dependency checking, compiling, or branching (as far as I can tell). Unless I&#39;m missing something, writing a portable shell script of that complexity would just involve putting the commands on consecutive lines, and putting a hashbang at the start.</p></pre>YEPHENAS: <pre><p>Go is also available on Windows and Plan 9. You&#39;d have to add a batch file and rc file for developers on these platforms.</p></pre>alaskacodes: <pre><p>In my opinion, there are two main things go generate gets you:</p> <ol> <li>a way to not depend on make (or things external to your go environment)</li> <li>the ability to distribute pre-compile build steps throughout your source code, placing each step someplace meaningful, like near the code it affects.</li> </ol> <p>As far as #1 is concerned, you&#39;ll notice that in the <a href="https://blog.golang.org/generate" rel="nofollow">blog posting</a> introducing go generate, nothing outside of $GOROOT/$GOPATH is referenced. So long as you don&#39;t stray from tools you can &#39;go get&#39;, then you can be reasonably sure that anything you need to perform your pre-build steps can run in the environment you&#39;re in.</p> <p>As for #2, it&#39;s just another level of organization. Just like godoc, it keeps the relevant metadata near the relevant code (or it can, depending on the standards you choose to hew to).</p></pre>