2012-03-27 23:39:01 +00:00
|
|
|
## bindata
|
2011-06-17 15:44:59 +00:00
|
|
|
|
|
|
|
This tool converts any file into managable Go source code. Useful for embedding
|
2012-06-13 12:17:25 +00:00
|
|
|
binary data into a go program. The file data is optionally gzip compressed
|
|
|
|
before being converted to a raw byte slice.
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2012-03-27 23:39:01 +00:00
|
|
|
### Usage
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2012-03-27 23:39:01 +00:00
|
|
|
The simplest invocation is to pass it only the input file name.
|
|
|
|
The output file and code settings are inferred from this automatically.
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
$ go-bindata testdata/gophercolor.png
|
2011-06-17 15:44:59 +00:00
|
|
|
[w] No output file specified. Using 'testdata/gophercolor.png.go'.
|
|
|
|
[w] No package name specified. Using 'main'.
|
2013-07-25 20:46:12 +00:00
|
|
|
[w] No function name specified. Using 'testdata_gophercolor_png'.
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2012-06-13 12:17:25 +00:00
|
|
|
This creates the `testdata/gophercolor.png.go` file which has a package
|
2013-07-25 20:46:12 +00:00
|
|
|
declaration with name `main` and one function named `testdata_gophercolor_png` with
|
2012-09-04 15:15:15 +00:00
|
|
|
the following signature:
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
```go
|
|
|
|
func testdata_gophercolor_png() []byte
|
|
|
|
```
|
2012-03-08 10:47:57 +00:00
|
|
|
|
2012-06-13 12:17:25 +00:00
|
|
|
You can now simply include the new .go file in your program and call
|
2013-07-25 20:46:12 +00:00
|
|
|
`testdata_gophercolor_png()` to get the (uncompressed) image data. The function panics
|
2012-06-13 12:17:25 +00:00
|
|
|
if something went wrong during decompression. See the testdata directory for
|
2012-06-22 12:12:15 +00:00
|
|
|
example input and output files for various modes.
|
2012-03-27 23:39:01 +00:00
|
|
|
|
2012-09-04 15:15:15 +00:00
|
|
|
Aternatively, you can pipe the input file data into stdin. `go-bindata` will
|
|
|
|
then spit out the generated Go code to stdout. This does require explicitly
|
|
|
|
naming the desired function name, as it can not be inferred from the
|
|
|
|
input data. The package name will still default to 'main'.
|
2011-06-17 15:46:29 +00:00
|
|
|
|
2012-06-13 12:17:25 +00:00
|
|
|
$ cat testdata/gophercolor.png | go-bindata -f gophercolor_png | gofmt
|
2011-06-17 16:52:40 +00:00
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
Invoke the program with the `-h` flag for more options.
|
|
|
|
|
|
|
|
In order to strip off a part of the generated function name, we can use the `-prefix` flag.
|
|
|
|
In the above example, the input file `testdata/gophercolor.png` yields a function named
|
|
|
|
`testdata_gophercolor_png`. If we want the `testdata` component to be left out, we invoke
|
|
|
|
the program as follows:
|
|
|
|
|
|
|
|
$ go-bindata -prefix "testdata/" testdata/gophercolor.png
|
2012-03-27 23:39:01 +00:00
|
|
|
|
|
|
|
|
2012-06-22 12:12:15 +00:00
|
|
|
### Lower memory footprint
|
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
Using the `-nomemcopy` flag, will alter the way the output file is generated.
|
2012-06-22 12:12:15 +00:00
|
|
|
It will employ a hack that allows us to read the file data directly from
|
|
|
|
the compiled program's `.rodata` section. This ensures that when we call
|
2012-09-04 15:15:15 +00:00
|
|
|
call our generated function, we omit unnecessary memcopies.
|
2012-06-22 12:12:15 +00:00
|
|
|
|
|
|
|
The downside of this, is that it requires dependencies on the `reflect` and
|
|
|
|
`unsafe` packages. These may be restricted on platforms like AppEngine and
|
|
|
|
thus prevent you from using this mode.
|
|
|
|
|
|
|
|
Another disadvantage is that the byte slice we create, is strictly read-only.
|
|
|
|
For most use-cases this is not a problem, but if you ever try to alter the
|
|
|
|
returned byte slice, a runtime panic is thrown. Use this mode only on target
|
|
|
|
platforms where memory constraints are an issue.
|
|
|
|
|
|
|
|
The default behaviour is to use the old code generation method. This
|
|
|
|
prevents the two previously mentioned issues, but will employ at least one
|
|
|
|
extra memcopy and thus increase memory requirements.
|
|
|
|
|
2013-03-09 12:37:09 +00:00
|
|
|
For instance, consider the following two examples:
|
2012-06-22 12:12:15 +00:00
|
|
|
|
|
|
|
This would be the default mode, using an extra memcopy but gives a safe
|
|
|
|
implementation without dependencies on `reflect` and `unsafe`:
|
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
```go
|
|
|
|
func myfile() []byte {
|
|
|
|
return []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a}
|
|
|
|
}
|
|
|
|
```
|
2012-06-22 12:12:15 +00:00
|
|
|
|
2013-03-09 12:37:09 +00:00
|
|
|
Here is the same functionality, but uses the `.rodata` hack.
|
2012-06-22 12:12:15 +00:00
|
|
|
The byte slice returned from this example can not be written to without
|
|
|
|
generating a runtime error.
|
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
```go
|
|
|
|
var _myfile = "\x89\x50\x4e\x47\x0d\x0a\x1a"
|
|
|
|
|
|
|
|
func myfile() []byte {
|
|
|
|
var empty [0]byte
|
|
|
|
sx := (*reflect.StringHeader)(unsafe.Pointer(&_myfile))
|
|
|
|
b := empty[:]
|
|
|
|
bx := (*reflect.SliceHeader)(unsafe.Pointer(&b))
|
|
|
|
bx.Data = sx.Data
|
|
|
|
bx.Len = len(_myfile)
|
|
|
|
bx.Cap = bx.Len
|
|
|
|
return b
|
|
|
|
}
|
|
|
|
```
|
2012-06-22 12:12:15 +00:00
|
|
|
|
|
|
|
|
2012-03-27 23:39:01 +00:00
|
|
|
### Optional compression
|
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
When the `-uncompressed` flag is given, the supplied resource is *not* GZIP compressed
|
2012-06-13 12:17:25 +00:00
|
|
|
before being turned into Go code. The data should still be accessed through
|
|
|
|
a function call, so nothing changes in the usage of the generated file.
|
|
|
|
|
|
|
|
This feature is useful if you do not care for compression, or the supplied
|
|
|
|
resource is already compressed. Doing it again would not add any value and may
|
|
|
|
even increase the size of the data.
|
2012-03-27 23:39:01 +00:00
|
|
|
|
|
|
|
The default behaviour of the program is to use compression.
|
2011-06-17 15:44:59 +00:00
|
|
|
|
2013-07-25 20:46:12 +00:00
|
|
|
|
|
|
|
### Table of Contents
|
|
|
|
|
|
|
|
With the `-toc` flag, we can have `go-bindata` create a table of contents for all the files
|
|
|
|
which have been generated by the tool. It does this by first generating a new file named
|
|
|
|
`bindata-toc.go`. This contains a global map of type `map[string] func() []byte`. It uses the
|
|
|
|
input filename as the key and the data function as the value. We can use this
|
|
|
|
to fetch all data for our files, matching a given pattern.
|
|
|
|
|
|
|
|
It then appands an `init` function to each generated file, which simply makes the data
|
|
|
|
function append itself to the global `bindata` map.
|
|
|
|
|
|
|
|
Once you have compiled your program with all these new files and run it, the map will
|
|
|
|
be populated by all generated data files.
|
|
|
|
|
|
|
|
**Note**: The `bindata-toc.go` file will not be created when we run in `pipe` mode.
|
|
|
|
The reason being, that the tool does not write any files at all, as it has no idea
|
|
|
|
where to save them. The data file is written to `stdout` instead after all.
|
|
|
|
|
|
|
|
|
|
|
|
#### Table of Contents keys
|
|
|
|
|
|
|
|
The keys used in the `go_bindata` map, are the same as the input file name passed to `go-bindata`.
|
|
|
|
This includes the fully qualified (absolute) path. In most cases, this is not desireable, as it
|
|
|
|
puts potentially sensitive information in your code base. For this purpose, the tool supplies
|
|
|
|
another command line flag `-prefix`. This accepts a portion of a path name, which should be
|
|
|
|
stripped off from the map keys and function names.
|
|
|
|
|
|
|
|
For example, running without the `-prefix` flag, we get:
|
|
|
|
|
|
|
|
$ go-bindata /path/to/templates/foo.html
|
|
|
|
|
|
|
|
go_bindata["/path/to/templates/foo.html"] = path_to_templates_foo_html
|
|
|
|
|
|
|
|
Running with the `-prefix` flag, we get:
|
|
|
|
|
|
|
|
$ go-bindata -prefix "/path/to/" /path/to/templates/foo.html
|
|
|
|
|
|
|
|
go_bindata["templates/foo.html"] = templates_foo_html
|
|
|
|
|
|
|
|
|
|
|
|
#### bindata-toc.go
|
|
|
|
|
|
|
|
The `bindata-toc.go` file is very simple and looks as follows:
|
|
|
|
|
|
|
|
```go
|
|
|
|
package $PACKAGENAME
|
|
|
|
|
|
|
|
// Global Table of Contents map. Generated by go-bindata.
|
|
|
|
// After startup of the program, all generated data files will
|
|
|
|
// put themselves in this map. The key is the full filename, as
|
|
|
|
// supplied to go-bindata.
|
|
|
|
var go_bindata = make(map[string] func() []byte)
|
|
|
|
```
|