On Tue, 2008-11-25 at 21:44 -0800, marcomaggi wrote: > "Derick Eddington" wrote: > > I haven't gotten around to looking at this, but I still plan to. > > Wait until Monday. I hope to upload the first official pre-release > this > week end (with a number of changes in the installation > infrastructure).
Is "Nausicaa" just this build+install framework, or a larger project? > DE wrote: > > Does it help with installing R6RS libraries using the common > > "./configure && make && make install"? > > Yes. The "configure" script is useful to: > > * select target directories; > * enable/disable installation of components (documentation > in different formats, fasl files); > * verify the availability of other libraries; Nice. > * inspect the value of constants in C language header files > and detect the size of data structures in foreign libraries; > * preprocess .sls files to make available the above values > at the Scheme level; There are already people who have this covered well, using Scheme macros. Felix Klock has investigated it and written a paper about it and we discussed it a little here: http://groups.google.com/group/ikarus-users/browse_thread/thread/93a5556aef3fa10a I think Felix just needs to find the time to port it to R6RS. I'm semi-planning to port it, if he doesn't have time, once his paper becomes available and I read it. I think it'll be a portable (probably using *.IMPL.sls) library we/somebody will integrate with a higher-level FFI layer that will be what's usually used by others and it'll be as behind-the-scenes, automated, and convenient as possible (using expand-time macros that exec GCC test-compile processes to figure things out), and your build framework will only need to consider it another normal dependency and check that it's already installed. > * offer the "at home" feeling to people used to it; > > the "make" phase is useful to build stuff, including source, > binary and package distributions along with some add-ons > like automatically generated uninstall shell scripts; the > "make install" step allows one to install everything to a > temporary location, where one can inspect things, change > permissions, etc. > > > Does it / will it support installing for different R6RS > > implementations? > > I have decided to install libs under "${prefix}/lib/scheme" > and to avoid enclosing everything in a namespace: there is > no "nausicaa" directory and no "nausicaa" element in the > import specs. I don't yet know what this implies, but if this build+install framework is going to be useful to others, the top-level namespace libraries are named under must be retained because it allows us to avoid library naming clashes as well as because that's what other code importing them names them as. IIRC, you've renamed the (xitomatl srfi ---) to (srfi ---) which is okay because putting them under (xitomatl ---) is just temporary because I don't claim (srfi ---) as mine and if/when SRFI-97 gets finalized (or something that actually gets finalized) I was planning to follow its names which will be under (srfi ---). But I certainly want any other libraries of mine and others' libraries to retain their top-level namespace. And I encourage you to do the same because you're only creating potential problems for yourself by not having your own top-level namespace because what will you do when you want to import both (Alice things) and (Bob things) but you've renamed one to just (things) before you needed the other. Anyways, there already should not be any problems using just one top-level directory and putting everybody's libraries in their own ${prefix}/lib/scheme/acme because you just tell the Scheme implementations to include ${prefix}/lib/scheme in their search paths. > > DE wrote: > > making it work for a variety of implementations might > > be more work than you care about > > Currently I am officially supporting only Ikarus, and > unofficially I try to make everything work with Ypsilon, > too (with the --compatible flag). > > I am successfully mobbing Fujita into adding some feature > to make this easier (like supporting "main.sls" and the > graph notation). > > The problem with Ypsilon is that I am not sure how the > (fully undocumented) ffi is to be used (especially memory > allocation protocol of blocks as bytevectors). I had to > rewrite "ffi.scm" to have functions available, rather than > syntaxes. I will see what happens. > > Regarding other implementations: I am not even sorry > that I am not trying to support them. ;-) It sounds like it should be relatively easy for others to add support for other implementations. -- : Derick ----------------------------------------------------------------
