Dear scsh hackers,
I am unfortunately a bit late with the work I had planned to do on the
packaging proposal. What I have done is a rewrite of the proposal
document, which is almost ready and includes the various suggestions
which were made during the discussion; I also made some additions to
the install library. For now, I have put them on a Web page related to
this proposal, whose address is:
http://lamp.epfl.ch/~schinz/scsh_packages/ (Martin, thanks for you
offer, I think that for now I'll use my web site at work, but once the
proposal stabilizes, I would be glad to put it on scsh.net or something
like that). I'll keep this page updated as I progress.
However, I didn't have time to work seriously on package definitions
for sunet, sunterlib or SSAX (sorry Anthony, this means I have nothing
to send you for Thanksgiving). But before working on them, I have two
--- *** ---
The first is directly related to the creation of these package
definitions, especially for sunet and sunterlib. The new version of the
proposal says that Scheme code should be put in a sub-directory of the
package installation directory called "scheme". For example, all Scheme
code related to sunet should be put in
<package_root>/installed/sunet/2.0/scheme. This was suggested by Martin
after I mentioned the conflict that would appear with sunet, which has
some Scheme code in a directory called "lib"; this conflicts with the
proposal, which reserves this directory for shared libraries. I adopted
the idea because I think that it is good to put all Scheme code in a
separate directory, as it helps keeping everything tidy.
Now the problem is that this requires changes to sunet's hierarchy, and
to its packages.scm file (which would have to be renamed anyway, but
that's a different matter). I see three ways of solving that:
1. we keep the files where they are now, both in sunet's CVS and in
sunet's archive, and deal with the problem by writing a relatively
complicated installation script which moves things to the correct
location and updates (and rename) the "packages.scm" file,
2. we (well, that would be "the sunet developers") change the hierarchy
of sunet's CVS to adapt it to the proposal, by moving all directories
containing Scheme code to a "scheme" sub-directory,
3. we forget about the idea of putting Scheme code in a "scheme"
sub-directory, and find another name for the directory in which to put
Solution 1 means that the installation script becomes relatively
complex, but solution 2 might even be more painful because of CVS'
inability to move files around cleanly. The sunet developers might also
feel uneasy about these changes, as the proposal is not stable yet, and
therefore other similar changes might arise in the future.
I would personally opt for solution 1 or 3, but I'd like to hear the
opinions of other people (especially developers of sunet and sunterlib).
--- *** ---
My second question is about shared libraries. The current version of
the proposal says that shared libraries should be put in a
sub-directory of directory "lib" and this directory should have the
name of the platform for which the library was compiled, as given by
"config.guess". Now the problem is that, to load these shared libraries
using "dynamic-load", the package loading script has to know their
complete path. To know that, it has to know the platform on which it is
currently running. I don't think it is possible, at least for the
long-term, to launch "config.guess" each time a package with a shared
library is loaded. The best solution, IMO, would be to use the
forthcoming interface providing access to configure parameters, the one
we talked about some time ago. However, Martin said he would add it in
scsh 0.7 only, so I'm wondering what to do until then. Or maybe this
would be a good reason to add it earlier, to 0.6.6 for example (I'm
really sorry I thought about this problem only after 0.6.5 was
released). What do you think ?
--- *** ---
Ok, so now I'll try to finish as quickly as possible what I was
supposed to finish yesterday. I'll put all the data I produce on the
web page mentioned above, and send messages here when I make some
I hope to have everything ready for next Monday.
In the meantime, if anybody is interested in reading and criticizing
the proposal, I would be very glad. And if some of you have spare time
on their hand and are interested in attempting to use the installation
library for some package, I'll also be glad. Just send me a quick
e-mail so that we avoid duplicating work.
Thanks, and sorry for another long mail.