I’m guessing that everyone who has a workflow where they currently embed resources in their binary will have specific wishes to how it’ll function.
The “easy” way to make serious proposals is to provide an experiment where you demonstrate the change you are proposing with an implementation - this will naturally require some work. My/our use of embedded resources include other programs but especially frontends (html, css, javascript and images, fonts etc.) for web servers - the current solution give us a crucial feature: The files are not embedded during development/debugging where they change continually. There is no doubt that I’d welcome this feature in the standard Go toolchain - where it is implemented or how the resource is embedded is not really something I have a strong opinion about - but debugging capabilities is ;-) -- Michael Banzon https://michaelbanzon.com/ > Den 2. maj 2018 kl. 14.35 skrev Manlio Perillo <manlio.peri...@gmail.com>: > > Il giorno mercoledì 2 maggio 2018 00:26:05 UTC+2, Ian Lance Taylor ha scritto: > On Tue, May 1, 2018 at 1:28 PM, John Unland <unlan...@gmail.com <>> wrote: > > > > So something like x/tools/cmd/assets or cmd/assets? > > Yes. I might use a name more like cmd/embed. > > > > I was just now thinking about it more today and I was wondering if > > something > > like this could maybe be implemented into go build. Like how you can assign > > variables at build time: > > > > go build -ldflags="-X main.Foo=Bar" > > > > Into something like... > > > > go build -ldflags="-X main.Asset1=./SomeFileA main.Asset2=./SomeFileB" > > > > Think this would take a little more effort to integrate in but it's a > > interesting concept thou. > > Personally I think the code generation approach is simpler. > > > It is simpler but, isn't it very inefficient with large assets, since the > compiler eats a lot of memory? > Maybe a better choice is to directly embed the code into the executable > image, as an example appending a zip archive at the end of the executable > (this at least works with ELF on Linux). > > Using a zip archive appended to the end of the executable, you don't even > need to record the offset. > The unzip tool just reports a warning: > warning [xxx]: ddd extra bytes at beginning or within zipfile > > I have not tested it with the archive/zip package. > > > Manlio > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
