# go-bindata (forked by tmthrgd)

[![GoDoc](https://godoc.org/github.com/tmthrgd/go-bindata?status.svg)](https://godoc.org/github.com/tmthrgd/go-bindata)
[![Build Status](https://travis-ci.org/tmthrgd/go-bindata.svg?branch=master)](https://travis-ci.org/tmthrgd/go-bindata)
[![Go Report Card](https://goreportcard.com/badge/github.com/tmthrgd/go-bindata)](https://goreportcard.com/report/github.com/tmthrgd/go-bindata)

This is a rewrite of go-bindata that started life as fork of a fork. It
was forked by [lestrrat](https://github.com/lestrrat/go-bindata) as
[jteeuwen](https://github.com/jteeuwen/go-bindata) seemed to have
abandoned the project.

Since that fork, go-bindata has been
[largely rewritten](https://github.com/tmthrgd/go-bindata/compare/3adb6a8b66f07a123c3d44e8f6c7e78bbdd029c2...master)
and has become a standalone project. While the generated code has changed,
the generated API remains backwards compatible. The
[package API](https://godoc.org/github.com/tmthrgd/go-bindata) is not
backwards compatible. The CLI remains backwards compatible, but may not be
as feature complete as the package API.

The suggested way of using go-bindata is from a single .go file with an
ignore build tag (`// +build ignore`) run with
`//go:generate go run path/to/generate.go`. (See
[issue #2](https://github.com/tmthrgd/go-bindata/issues/2#issuecomment-290957538)
for reference).

*Nota bene*: Most of the README that follows has not been updated to match
the changes made since rewriting go-bindata and likely does not accurately
represent the state of go-bindata.

## bindata

This package converts any file into manageable Go source code. Useful for
embedding binary data into a go program. The file data is optionally gzip
compressed before being converted to a raw byte slice.

### Installation

To install the library, use the following:

	go get -u github.com/tmthrgd/go-bindata/...

### Accessing an asset

To access asset data, we use the `Asset(string) ([]byte, error)` function which
is included in the generated output.

	data, err := Asset("pub/style/foo.css")
	if err != nil {
		// Asset was not found.
	}

	// use asset data


### Debug vs Release builds

When invoking the program with the `-debug` flag, the generated code does
not actually include the asset data. Instead, it generates function stubs
which load the data from the original file on disk. The asset API remains
identical between debug and release builds, so your code will not have to
change.

This is useful during development when you expect the assets to change often.
The host application using these assets uses the same API in both cases and
will not have to care where the actual data comes from.

An example is a Go webserver with some embedded, static web content like
HTML, JS and CSS files. While developing it, you do not want to rebuild the
whole server and restart it every time you make a change to a bit of
javascript. You just want to build and launch the server once. Then just press
refresh in the browser to see those changes. Embedding the assets with the
`debug` flag allows you to do just that. When you are finished developing and
ready for deployment, just re-invoke `go-bindata` without the `-debug` flag.
It will now embed the latest version of the assets.


### Lower memory footprint

Using the `-nomemcopy` flag, will alter the way the output file is generated.
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 our generated function, we omit unnecessary memcopies.

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.

For instance, consider the following two examples:

This would be the default mode, using an extra memcopy but gives a safe
implementation without dependencies on `reflect` and `unsafe`:

```go
func myfile() []byte {
    return []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a}
}
```

Here is the same functionality, but uses the `.rodata` hack.
The byte slice returned from this example can not be written to without
generating a runtime error.

```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
}
```


### Optional compression

When the `-nocompress` flag is given, the supplied resource is *not* GZIP
compressed 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.

The default behaviour of the program is to use compression.


### Path prefix stripping

The keys used in the `_bindata` map, are the same as the input file name
passed to `go-bindata`. This includes the path. In most cases, this is not
desirable, 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/

	_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/

	_bindata["templates/foo.html"] = templates_foo_html


### Build tags

With the optional `-tags` flag, you can specify any go build tags that
must be fulfilled for the output file to be included in a build. This
is useful when including binary data in multiple formats, where the desired
format is specified at build time with the appropriate tags.

The tags are appended to a `// +build` line in the beginning of the output file
and must follow the build tags syntax specified by the go tool.

## Testing

To execute the test case, run the following commands:

	go get -t -u github.com/tmthrgd/go-bindata
	go test github.com/tmthrgd/go-bindata

### Test corpus

To generate the corpus-sha256sums needed for travis, run the following commands:

	[ -d .testcorpus ] && rm -r .testcorpus
	go test -run TestCorpus -randtests 50 -corpus .testcorpus -gencorpus .
	cd .testcorpus && sha256sum * > ../corpus-sha256sums; cd ..

This must be done every time the generated code changes, but can be skipped while working
on a pull request until it is ready to merge.