> From: Taylor R Campbell <campb...@mumble.net> > Date: Sun, 19 May 2013 23:13:35 +0000 > > [...] > > At the very least it should be possible to work in the working > directory without touching MITSCHEME_LIBRARY_PATH or anything in it, > just like we can (cf "foo") and then (load "foo").
At the very, VERY least it should work, withOUT regard to your current working directory. I think your analogy to .bin/com's is at fault here. You might think of (C-include "fubar") as a syntax-time (load-option 'fubar) instead. If you consider that it prepares to generate code that will on-demand dlopen fubar-shim.so at a later date, then it might not seem so wise to search the *current* working directory. It definitely seems NOT wise to someone who is particular about what he dlopens. Who loads a shared library from the current working directory? Surely such types can be asked to add "--library lib" to their build scripts (when not in the grip of riastradh). > That way, there is a chance we could write automatic tests for it > that don't mess with the installed files. Speaking of which, do you > have any automatic tests for the FFI? > [...] > > MIT Scheme doesn't currently support cross-compilation at all (which > is a bug to be fixed, not to be encouraged) You are just trolling now. > what it does support is sharing compiled code and bands between > operating systems which have different ABIs. Storing the output of > the groveller in compiled code or in bands will break this -- even > for interpreted-only bands. Create-thread also breaks this, ever since someone added the near- useless, ABI-dependent floenvs and stuck one in each thread. In (my) practice the ABI dependence only goes so far. For example my implementation of Edwin's Gtk screens uses no (C-... ) syntax. The FFI option is not needed. It DOES load-option ABI-dependent .bin/com's containing code that will on-demand dlopen a gtk-shim.so, but the Gtk Screen implementation itself is ABI independent. Its .bin/com's can use Gtk options wrapping all kinds of toolkits -- different versions, architectures, operating systems... _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
