Anthony Carrico <acarrico@memebeam.org> writes:
> Hello scsh-hackers,
>
> Today I uploaded Sunterlib 0.5, which adds two new libraries. I
> anticipate that the only changes in 0.6 will be related to the
> packaging proposal.
>
> I have some questions about Sunterlib and the new packaging proposal:
>
> 1. Sunterlib is a collection of a bunch of unrelated libraries.
> Therefore I think each sub-library should be installed in the top
> level of the hierarchy. Do you agree?
I think it makes sense, yes, that gives the user a much more
fine-grained view of the library.
[...]
> 2. Sunterlib also includes Scheme48 libraries. Where should they go
> in the new regime? In lib/scsh/modules? This seems a little strange.
> Should our module tree be outside of lib/scsh to account for
> Scheme48 libraries?
Since there is currently no packaging standard for Scheme48, I think
that it would make sense to install them at the same location as the
scsh libraries, yes.
I think we can view it that way: what we provide is a standard which
says where to put Scheme code so that it can be used easily from scsh.
But the Scheme code that we put there does not have to be Scheme48 or
scsh specific; it can be but doesn't have to. I can very well imagine
that we could provide simple wrappers around pure R5RS libraries which
have nothing to do with Scheme48 or scsh. Basically we would provide
an install script and a module definition. (And that's exactly what
happens already now with some sub-parts of sunterlib, which are pure
R5RS except for the module definition). Some SRFIs could be
distributed like that, for example.
[...]
> 3. The files "sunterlib-s48.scm" "sunterlib.scm" currently contain
> the interfaces and packages definitions for all of sunterlib and the
> s48 subset respectively, What should happen to these? Should they go
> into a "sunterlib" super library?
That could be an idea, yes. I'm just wondering whether this makes
sense as many of the individual libraries which make up sunterlib have
very little in common. It's probably a good idea to keep them anyway,
to provide backward compatibility.
Anyway, this looks like a nice problem to test the flexibility of the
current proposal, in particular the install script. I'd like to try to
make an install script which first installs all the individual
libraries, and then defines and install the "meta-library". Or, if you
already started working on this, you could do it and tell me how well
the current install library copes with that. Or we can collaborate,
whatever.
I think this concept of having meta-libraries could be an interesting
one anyway. If it happens often that several libraries are used
together, then a meta-library could provide a shortcut to use them all
with a single -lel switch.
Michel.
|