Michel Schinz <Michel.Schinz@epfl.ch> writes:
> 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.
I did not have the time to read through the proposal but I would like
to address your questions below already. Anyway, thanks for your
effort.
> 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
> questions.
>
> --- *** ---
>
> 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
> shared libraries.
>
> 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).
I would vote for 2 but I could live with 1. 3 looks ugly to me. For
sunet we need Mike's and Andreas' agreement, too and I guess we would
move the files directly in the repository.
As for 1, I don't think the installation procedure would have to
update the packages.scm file as it would go to scheme/ to.
> --- *** ---
>
> 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 ?
This is exactly the issue that I'm contemplating right now. If you
check out the scx module in CVS, you will notice that the Makefile
produces a file scheme/load-scx.scm that loads the dynamic
library. The installation path is currently lib/`uname -m`-`uname -s`
I did not use $host for the reason you mentioned above: I would have
to call config.guess to access this value from Scheme.
But the uname approach still has a problem: on Linux I would get
i686-... on a Pentium 4 box but a Debian maintainer would like to
install the package for *all* x86 architectures.
With $host it's even worse because I get i386-unknown-freebsd4.6.2 on
my FreeBSD box but would obviously like to install for FreeBSD 4.x or
something (Note that on FreeBSD the machine is "correct").
I just realized that adding access to the configure parameters would
work around this problem by tying the value to the one scsh was built
on.
So it really looks as if we need some support from scsh right away but
0.6.6 will surly take some time to release[1]. For the time being we
could define an additional library that approximates the value using
uname.
Footnotes:
[1] I didn't expect the release name to become adequate *that fast* ;-]]]
--
Martin
|