>> There are some theoretical corner cases where it could be useful. >> Don't know if these would ever occur in practice. >> - Systems that don't use a Unix-like filesystem heirarchy > > I also don't see how Unix-like filesystem semantics affect this > question. If there were a go archive, I could finally make a port to MS-DOS because I could ignore the 8.3 filesystem limitation. ;-) > If this single file is to be built only during the package build > process, and never modified after that, then it should be super-easy to > invent your own little homebrew format. If we assume that the library, > executable, and go-bundle files are always distributed together, that > also means that we're free to change the format at will. I guess it > could be as simple as this: > > * Concatenate all of the .go files together, making sure to align each > .go file on a page boundary (4 kilobytes) so that each one can be > individually mmapped. > > * Generate a C file that includes the entire directory of files within > an initialized array. It could be as simple as an array of structs > with three fields: module name, start offset in the big file, and > length. If you sort this array by module name before generating the > file, then you could use binary search to find the file. > > * Once the C file is generated, relink libguile with this file included. > (The first time libguile is built, it could include a stub version of > the C file with an empty directory, so that it knows to use the > traditional module-loading mechanism). > > * To allow graceful error messages in case the wrong go-bundle is used > with the wrong library, there should be some kind of fingerprint put > in both the go-bundle and the C file index. Check the fingerprint > before trying to load things from the go-bundle.
That's good advice. Thanks much, Mike Gran
