name collisions in the generated code, when it comes to
multiple assets with the same file name.
This should all receive unique entries, using their
directory paths to set them apart.
modes. For debug we always read assets from disk and ignore
the compression and memcopy options. For release mode, the
assets are all embedded and the compression/memcopy options
are taken into account.
of the target file, instead of just the target directory.
This allows us to overwrite a generated file from a previous
build cycle. This addresses issue #8
This now expects a directory path to store the generated file(s) in.
This was previously a path with file name. We now always use
the filename, inferred from the input path.
We do this, because the changes in this patch fundamentally
alter the way code is generated by the tool. This will, in some
cases, be incompatible with older versions.
* Performs cleanup and minor code fixes.
* Adds two new command line flags:
* -prefix: This accepts a partial path. It is used when generating
a target function name, as well as the key for the Table of Contents
map (see below). The specified prefix is applied to the input
file name, causing the prefix section to be stripped from the
input file path. E.g.:
```
input: /path/to/foo.x
prefix: /path/to
output: /foo.x
```
* -toc: This is a boolean flag which tells the tool to generate
a table of contents for the generated data files. It creates
a separate 'bindata-toc.go' file, which defines a global map
named `go_bindata`. It then appends an `init` function to the
generated file. This function makes the data function register
itself with the global map.
* Fixes the function names the tool infers from input file names
to include the full path. This fixes potential name collisions
when the same file name is processed from different directories.
For example, we can now safely import the following two files:
```
input file: css/ie/foo.css
output function: css_ie_foo_css()
input file: css/chrome/foo.css
output function: css_chrome_foo_css()
```
generate a segfault when there are too many string
concatenations. This happens when we convert a file of
about 100kb or larger.
The fix modifies the StringWriter to write the file data
out into a single, long string, without concatenations.
This addresses issue #5
ByteWriter and StringWriter were returning n-1 bytes written which was
causing io.Copy to error out with a ShortWrite. This would cause files
that were larger than the io.Copy internal buffer (32 * 1024) to stop
after the first chunk.
