<p>Can a golang executable produce another golang executable? I don't want to use os/exec together with go build. </p>
<hr/>**评论：**<br/><br/>dlsniper: <pre><p>Yes, the go compiler is written in Go. What problem are you trying to solve? Why is go build via os/exec not an option?</p></pre>miggimaggi: <pre><p>Ok, that means i have to copy over the go build sourcecode? I am looking for a library or api to do that.
My problem is like you want to deliver to your clients an office package bundled with the documents to edit. So that the client needs no separate install of the office package.
The clients themselves have no go sdk installed generally.</p></pre>stone_henge: <pre><p>So you want to attach the documents as data attached to the binary? You don't need to recompile to do that. You can just concatenate your data to the executable and read it like any file.</p></pre>dlsniper: <pre><p>Can you not use a separate file to store these things, like a sqlite database? Or any of the other embeddable dbs written in Go? </p></pre>miggimaggi: <pre><p>Binary A produces Binary B.
'A' bundles documents with the office program to produce B which lets clients edit the documents directly by calling B.
The problem is here, a client , who in generally does not have golang sdk installed, should also produce B's from an A what ist delivered to him. That is why i need to produce a binary A, which does not use go build. Binary B does not produce a binary, only 'A'.</p></pre>epiris: <pre><p>XY problem, but from how you describe this makes little sense. It's akin to PDF files containing a C++ compiler to "compile" changes to itself each time you save, including the old compiler each time. No one would ever do this, you shouldn't either. Security alone is reason enough, if you ever need to email one of these things and get a new one.. you are asking your users to compile software they got from smtp. </p>
<p>Create a client (PDF reader for your app) .. and settle on a format for documents if they have to contain metadata so be it- better a homegrown binary or haggard text format for documents than people in your office passing around documents containing a compiler... lol. A easy solution would be to use the tar or a zip pkg to have the client use the function that gets he path of the executable they added in 1.8 to put itself and derivative documents in a archive. Most people can open a tar or zip and when they use your binary to make changes it will pass itself along. I really don't suggest this though if it will ever be received from a untrusted source. You should just have a secure canonical download location for your client.</p></pre>miggimaggi: <pre><p>i want to deliver one binary 'A', nothing more.</p></pre>epiris: <pre><p>That isn't what your post says, try explaining your problem or I'm not sure anyone can help.</p></pre>sethammons: <pre><p>Why not have binary A and binary B be the same binary with different options? A copies itself and puts the documents in sqlite and writes a new start up script with the right options (start mode, sqlite db location, etc). Another option would be to have your binary A trigger a job on your remote server that compiles the new binary B and returns it over the network to A to be written to disk.</p></pre>miggimaggi: <pre><p>Thank you!
Triggering a regular remote golang compiler sounds heavy but maybe feasible. A and B cannot be the same, because B contains documents, A not. Delivering documents separately from B is not allowed in this use case.</p></pre>jerf: <pre><p>It might be theoretically possible if you put enough work into it, but if you look at all the resources the Go compiler touches in the process of building a non-trivial program, you have to include all of them and set it up somehow so the compiler isn't looking on the file system for them. So you're going to be embedding the full source code of the standard library, the full source code of any other libraries you may want to build, and the full source code of everything that goes into your secondary binary. (You could try to ship the .a files alone out of the $GOPATH/pkg dir, but I would consider that much more fragile.) It's going to be a crapton of work (technical term) and it is way easier to simply ship a full copy of the Go compiler and use it normally than to undertake all that work. I can imagine ways to do this but none of them are even <em>remotely</em> worth it.</p></pre>
