This is an interesting point. I was thinking about it though, and I think there is another thing that is causing a lot of this "bloat": all of the Scheme modules we are adding.
There is a tension here, because having lots of modules is very important for using Guile as a language to write programs in. But when it is used as an extension to other languages, most of them are not useful. So if I were dreaming and not thinking about how hard it is to write code, I would get a system that lets me pick which modules I want to distribute and bundle them up with libguile into a package that can be distributed and built on its own. This would also end up addressing some of your examples, if this hypothetical packager grew the ability to know about C as well as Scheme modules. Then it could automatically remove the C code that implements functions that were not wanted. This is just an idea, though. This seems like a huge pain to code. Noah On Mon, Dec 19, 2011 at 3:35 PM, Mike Gran <[email protected]> wrote: > Hi- > > I've been keeping up with some of the discussion on other gnu lists. > > One of the criticisms at the moment is that Guile is > > 1. bloated > 2. hard to distribute. > > Re point 2: hard to distribute. > > A while ago I was looking at the idea of minimizing the number of > files needed to ship Guile as a dependency. At the time, I thought > that one could retool the build so that it produced > - a tar.gz of the distributable header files > - libguile as a monolithic .so or .dll with no dependencies. > Dependencies would be wrapped into the monolithic .so or .dll. > - all the compiled .go files as a tar file > - and a Guile executable that used both of the above > > Guile and libguile would read the .go without unpacking the tar file > by using libtar. > > There's no real advantage in this for the GNU system, but, it would > make it easier to make a distributable cross-build for non-GNU > systems. This would make it easier to set up a download repository > of prebuilt .so, .dll, and go-lib tar files. > > Re point 1: bloated > > Once the infrastructure for the above is in place, one could set > up an alternate cross-build system that produced a version of > Guile that is > > - ASCII only, "C" locale only > - Fixnum integers only > - No ability to load ltdl or ffi > - no ability to use whatever libcrypt is used for > > This would be for the purpose of being a minimalist extension > engine. > > What do you think? > > -Mike Gran >
