lu4p / binclude Goto Github PK

Currently including the same files leads to different output because maps are randomly ordered.

https://blog.golang.org/maps#TOC_7.

Is it possible to use binclude to selectively include files based on build tags? For instance, if I am building for windows amd64, include X file?

//+build windows

import "github.com/lu4p/binclude"

binclude.Include("/windows-thing.dll")

I may be using the API incorrectly. binclude.Include always expects string literal.
binclude.Include(fmt.Sprintf("%s", "./out/myexe"))
Does not work and give error

[binclude] 2020/06/26 06:09:47 argument is not string literal

Is there a way to avoid this, I am looking for reading the file name from say input json

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

I'm using windows 10 and the generated BinFS map has \ in it's keys as path seperator.
Generated error with value at that point \r: .\binclude.go:54:54: unknown escape sequence.

This is something I've never done before, an anti-feature request :)

You recently added optional GZip and Brotli support. They cover the same use case, with Brotli offering slightly better filesizes. Since Brotli isn't supported by Go by default, you had to pull in the github.com/andybalholm/brotli package. This package is anything but small:

❯ gocloc brotli
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Go                              61           2451           1941         252967
Plain Text                       1            815              0           8471
Markdown                         1              1              0              4
-------------------------------------------------------------------------------
TOTAL                           63           3267           1941         261442
-------------------------------------------------------------------------------

Is an optional feature worth adding 260k lines of code? I'd argue no. Furthermore, aletheia-icu/broccoli already covers the "embed files with brotli compression" use case, for those interested in it (and not afraid of the large dependency).

Here's an official feature request, repeating what I said on Reddit:

 I would appreciate being able to run the generator from my own _gen.go file, instead of having to rely on the binclude binary (which requires ensuring I have installed it up front, and I guess maintaining a tools.go file for that purpose).

This would require moving the relevant code from cmd/bininclude to the parent package, so that it can be called both by random callers and the CLI.

Right now only vfsgen in the entire ecosystem supports this, so it would be a big plus for this package to cover it.

When I run binclude, some of the time the generated code does not match go fmt so I have to run go fmt against the file after generation. Specifically there is extra space between the variable declarations and the = sign that needs to be removed:

Current binclude generated output

After I run go fmt

The os/exec wrapper is a really useful feature. As I understand the feature it copies the embedded byte slice to a temporary file in the os.CacheUserDir(), executes it, and then removes it. This is a sane default, but if the embedded binary is large (in my case, 80mb), this will take a long time to copy and use each time. I wonder if there should be an option to disable the removal, and a potential warning logged when calling os/exec on a large binary, or if this is a feature that people should just implement on their own (extracting the embedded file to wherever and calling os/exec on it). I can really see this -not- being a feature that is added, but if it is not, I wonder if there should be some documentation or warning that this could be expensive for large binaries because it copies them each time.

I am trying for binary files, but I am always getting error

binclude.Include("./out/MyExe")

err := example.BinFS.CopyFile("MyExe", filepath.Join(destination, "MyExe"))
		if err != nil {
			fmt.Printf("1 :: Failed to copy file to destination, error = %v\n", err)
			//os.Exit(1)
		}
		err = example.BinFS.CopyFile("out/MyExe, filepath.Join(destination, "MyExe"))
		if err != nil {
			fmt.Printf("2 :: Failed to copy file to destination, error = %v\n", err)
			//os.Exit(1)
		}
		err = example.BinFS.CopyFile("./out/MyExe", filepath.Join(destination, "MyExe"))
		if err != nil {
			fmt.Printf("3 ::Failed to copy file to destination, error = %v\n", err)
			//os.Exit(1)
		}