Before there was a wide range of tools for embedding assets, I wrote my own. It is relatively complete, but it did not have a feature to create a debug mode for assets. However, the server took a command-line flag for debug mode, and would access assets through the file system instead of the embedded data.
The point being, the "standard" tool would not have to support everything, it could be a building block for other packages. The key functionality would be embedding possibly large assets into the linked executable. I haven't measured in a while, but embedding assets did have a significant impact on build times. Finding the most efficient technique would be a usable block, all on its own. Additional conveniences could be built on top. Robert On Wednesday, 2 May 2018 10:36:43 UTC-4, mbanzon wrote: > > 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....@gmail.com > <javascript:>>: > > 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...@googlegroups.com <javascript:>. > For more options, visit 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.
