bindata

package module
v0.0.0-...-5016576 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Oct 9, 2014 License: CC0-1.0 Imports: 14 Imported by: 1

README

bindata GoDoc Build Status Build Status Build status

bindata is a fork of jteeuwen/go-bindata by jteeuwen branched off at d3feb9534c with changes not meant to be pushed to the upstream repository.

This package converts any file into managable 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.

It comes with a command line tool in the bindata sub directory. This tool offers a set of command line options, used to customize the output being generated.

Installation

~ $ go get -u github.com/rjeczalik/bindata

Documentation

godoc.org/github.com/rjeczalik/bindata

cmd/bindata GoDoc

Installation

To install the library and command line program, use the following:

~ $ go get -u github.com/rjeczalik/bindata
~ $ go install github.com/rjeczalik/bindata/cmd/bindata

Documentation

godoc.org/github.com/rjeczalik/bindata/cmd/bindata

Automagic conversion within $GOPATH workspace

When no input files nor directories are provided via command line flags, bindata reads $GOPATH workspaces and attempts to convert all files it finds recursively in $GOPATH/data, generating a bindata.go file in a matching $GOPATH/src directory. The match is always the longest path diff between $GOPATH/data and $GOPATH/src, in order to avoid having assets which content overlaps. For example, running:

  ~ $ GOPATH=/home/user bindata

over the following $GOPATH workspace:

  /home/user
  ├── data
  │   ├── bitbucket.org
  │   │   └── user
  │   │       └── hidden
  │   │           └── subpackage
  │   │               ├── aws.txt
  │   │               └── pass.txt
  │   └── github.com
  │       └── user
  │           └── example
  │               └── assets
  │                   ├── css
  │                   │   └── default.css
  │                   └── js
  │                       ├── app.js
  │                       └── link.js
  └── src
      ├── bitbucket.org
      │   └── user
      │       └── hidden
      │           ├── hidden.go
      │           └── subpackage
      │               └── subpackage.go
      └── github.com
          └── user
              └── example
                  └── example.go

will create two asset files under the following paths:

  ~ $ GOPATH=/home/user bindata
  ok      bitbucket.org/user/hidden/subpackage    (/home/user/src/bitbucket.org/user/hidden/subpackage/bindata.go)       0.001s
  ok      github.com/user/example (/home/user/src/github.com/user/example/bindata.go)    0.002s

Running bindata in this mode will ignore any values passed by -o, -pkg and -prefix flags.

Documentation

Overview

bindata converts any file into managable 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.

The following paragraphs cover some of the customization options which can be specified in the Config struct, which must be passed into the Translate() call.

Automatic conversion within $GOPATH workspace

When no input files nor directories are provided via command line flags, go-bindata reads $GOPATH workspaces and attempts to convert all files it finds recursively in $GOPATH/data, generating a bindata.go file in a matching $GOPATH/src directory. The match is always the longest path diff between $GOPATH/data and $GOPATH/src, in order to avoid having assets which content overlaps. For example, running:

~ $ GOPATH=/home/user go-bindata

over the following $GOPATH workspace:

/home/user
├── data
│   ├── bitbucket.org
│   │   └── user
│   │       └── hidden
│   │           └── subpackage
│   │               ├── aws.txt
│   │               └── pass.txt
│   └── github.com
│       └── user
│           └── example
│               └── assets
│                   ├── css
│                   │   └── default.css
│                   └── js
│                       ├── app.js
│                       └── link.js
└── src
    ├── bitbucket.org
    │   └── user
    │       └── hidden
    │           ├── hidden.go
    │           └── subpackage
    │               └── subpackage.go
    └── github.com
        └── user
            └── example
                └── example.go

will create two assets files under he following paths:

~ $ GOPATH=/home/user go-bindata
ok      bitbucket.org/user/hidden/subpackage    (/home/user/src/bitbucket.org/user/hidden/subpackage/bindata.go)       0.001s
ok      github.com/user/example (/home/user/src/github.com/user/example/bindata.go)    0.002s

Running go-bindata in this mode will ignore any values passed by -o, -pkg and -prefix flags.

Debug vs Release builds

When used with the `Debug` option, 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

The `NoMemCopy` option 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 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`:

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.

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

The NoCompress option indicates that the supplied assets are *not* GZIP compressed before being turned into Go code. The data should still be accessed through a function call, so nothing changes in the API.

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

_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 field, 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.

Index

Constants

This section is empty.

Variables

This section is empty.

Functions

func Generate

func Generate(c *Config) (err error)

Generate translates configured assets into Go code and performs additional postprocessing if configured.

func GlobGenerate

func GlobGenerate(cfgs []*Config, log func(*Config, time.Duration, error)) bool

GlobGenerate runs Generate concurrently over cfgs configuration list. It logs execution time and eventual errors via user-provided log function. It returns true when all executions of Generate were successful, false otherwise.

func Translate

func Translate(c *Config) error

Translate reads assets from an input directory, converts them to Go code and writes new files to the output specified in the given configuration.

Types

type Asset

type Asset struct {
	Path string // Full file path.
	Name string // Key used in TOC -- name by which asset is referenced.
	Func string // Function name for the procedure returning the asset contents.
}

Asset holds information about a single asset to be processed.

type ByteWriter

type ByteWriter struct {
	io.Writer
	// contains filtered or unexported fields
}

func (*ByteWriter) Write

func (w *ByteWriter) Write(p []byte) (n int, err error)

type Config

type Config struct {
	// Name of the package to use. Defaults to 'main'.
	Package string

	// Tags specify a set of optional build tags, which should be
	// included in the generated output. 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.
	Tags string

	// Input defines the directory path, containing all asset files as
	// well as whether to recursively process assets in any sub directories.
	Input []InputConfig

	// Output defines the output file for the generated code.
	// If left empty, this defaults to 'bindata.go' in the current
	// working directory.
	Output string

	// Prefix defines a path prefix which should be stripped from all
	// file names when generating the keys in the table of contents.
	// For example, running without the `-prefix` flag, we get:
	//
	// 	$ go-bindata /path/to/templates
	// 	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
	Prefix string

	// Fmt defines whether generated file should be formatted afterwards with
	// gofmt command.
	Fmt bool

	// NoMemCopy 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
	// call our generated function, we omit unnecessary mem copies.
	//
	// 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`:
	//
	// 	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.
	//
	// 	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
	// 	}
	NoMemCopy bool

	// NoCompress means the assets are /not/ GZIP compressed before being turned
	// into Go code. The generated function will automatically unzip
	// the file data when called. Defaults to false.
	NoCompress bool

	// Perform a debug build. This generates an asset file, which
	// loads the asset contents directly from disk at their original
	// location, instead of embedding the contents in the code.
	//
	// This is mostly useful if you anticipate that the assets are
	// going to change during your development cycle. You will always
	// want your code to access the latest version of the asset.
	// Only in release mode, will the assets actually be embedded
	// in the code. The default behaviour is Release mode.
	Debug bool

	// Recursively process all assets in the input directory and its
	// sub directories. This defaults to false, so only files in the
	// input directory itself are read.
	Recursive bool

	// Ignores any filenames matching the regex pattern specified, e.g.
	// path/to/file.ext will ignore only that file, or \\.gitignore
	// will match any .gitignore file.
	//
	// This parameter can be provided multiple times.
	Ignore []*regexp.Regexp
}

Config defines a set of options for the asset conversion.

func Glob

func Glob(list string) ([]*Config, error)

Glob searches paths provided by a os.PathListSeparator-separated list. It looks for longest matching path between $GOPATH/data and $GOPATH/src directories - the former is used as an input source, the latter - an output one. The matching part of the paths is treated as a prefix. Glob uses BFS-like lookup.

Example

For the following $GOPATH workspace:

.
├── data
│   └── github.com
│       └── user
│           └── example
│               └── assets
│                   ├── css
│                   └── js
└── src
    └── github.com
        └── user
            └── example

Glob will create single Config, where the prefix would be "github.com/user/example", the files would get read recursively from the "assets" directory and outputted to the "./src/github.com/user/example/bindata.go" file.

func NewConfig

func NewConfig() *Config

NewConfig returns a default configuration struct.

type InputConfig

type InputConfig struct {
	// Path defines a directory containing asset files to be included
	// in the generated output.
	Path string

	// Recusive defines whether subdirectories of Path
	// should be recursively included in the conversion.
	Recursive bool
}

InputConfig defines options on a asset directory to be convert.

type StringWriter

type StringWriter struct {
	io.Writer
	// contains filtered or unexported fields
}

func (*StringWriter) Write

func (w *StringWriter) Write(p []byte) (n int, err error)

Directories

Path Synopsis
cmd
bindata
Usage Conversion is done on one or more sets of files.
Usage Conversion is done on one or more sets of files.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL