These are just some thoughts on improving the install script. It's been useful for some, but has proven to be a bit brittle.
Its current behaviour is to assume only top level library files have the .sls extension. Those are run through a preprocessor, installed to the destination directory and listed in the generated compile-all script, which is then executed (in order to fully compile the libs).
The preprocessor acts like a C-preprocessor #include
for the local macro include/resolve so the contents of the referenced file are inlined in the installed version of the file.
The problem this solved (as include/resolve
would only ever evaluate the code at runtime) was that inlining enabled full pre-compiles, pre-compiled srfi libs started up noticably faster on slow machines and some extra errors were caught.
I think one part of this task is to try and replace all that with an include/resolve
that resolves the provided path specifier at compile time and passes that to include as include
can compile the sourced file.
eg, (include/resolve (("srfi" "%3a115") "regexp-impl.scm"))
would resolve to:
(include "srfi/:115/regexp-impl.scm")
or
(include "srfi/%3a115/regexp-impl.scm")
depending on what's locally installed.
If that works, then there's no need to preprocess files and using these libs in-place would also have the benefits of pre-compiles.
So then the question is would an install process be needed? Or does the install process become link-dirs and maybe a compile step as well? Is it useful to install compiled binaries only?
I think the compile component of the install script would still be useful. Adding whole program optimisation files would be great for those using srfi's in compiled programs.
But the issue there is determining what are the top level library files, as those files are the inputs to compile-library.
Is it okay to restrict the .sls extension to the top level libfiles only? Is there a better way to auto-discover top level files?
Or should the compile process be driven from a file? Maybe registry-names.sls?
It would need to handle srfi's that define multiple top level libs. eg, (srfi :146) and (srfi :146 hash) are distinct top level interfaces provided by the one srfi.