Re: Minimal Guile

[Mike Gran]

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