Le Lundi, 9 fév 2004, à 07:21 Europe/Zurich, Anthony Carrico a écrit :
Sunterlib is organized as a collection of independent libraries. I
would like to keep them independent, so I envision each library having
a local pkg-def.scm for example:
So, I've given some thought to this issue, and have come to the
conclusion that I need a bit more information about what we want to
provide exactly before going further.
The main question I have can be summarised as: What relationship is
there between the "master" package (sunterlib) and the "sub-packages"
(args-fold and others)? I see basically two possibilities.
The first one would be to say that sub-packages are completely
independent from the "master" package. This would mean that each
sub-package would be completely self-contained, and the user would have
the choice to either install every package individually, simply by
running "install-pkg" in their directories, or the whole bunch of them
(i.e. sunterlib) by running the main "install-pkg". The install library
would provide a single function, say "install-package", which would
take a directory name and would install the package contained there.
This could be defined as follows (although there could be more
(define (install-package dir)
(with-cwd dir (run (./install-pkg ,@master-options))))
(This assumes that every directory contains a copy, or a link, to the
files which make up the installation library, but this is a minor
With this solution, we would have several "load.scm" files: one per
sub-package, and one for the main package which would do nothing more
than load all the others.
The main problem I see with this solution is that there is no real way
to communicate values between the master package and the sub-packages,
apart from the command-line options. This means that additional options
defined by the sub-packages would not be seen when installing them
through the main package. It's not as bad as it sounds, I think, since
it simply means that the main "pkg-def.scm" has to be written in such a
way that it accepts the union of all options defined by sub-packages,
and passes them further. The nice thing about this solution is that
sub-packages are self-contained and users can "cherry-pick" the ones
they are interested in.
The second solution would be to introduce the notion of sub package.
There could be bi-directional communication of values between a master
package and its sub-packages, for example so that sub-packages can
communicate options to the master, or so that the master package can
define variables to be used by sub-packages. A sub-package could be
defined with a different form than define-package (say
define-sub-package) to make sure that a user trying to install it
separately would get an error.
This solution would raise several questions, like how to organise the
installed files: Should all sub-packages have their own small
hierarchy, like normal packages, or should there be only one hierarchy
for the master package in which sub-packages would appear? In other
words, would sunterlib look like one single package once installed, or
like several, as in the first solution above? Another question is how
the "load.scm" script would be generated. Could each sub-package
contribute to its contents, or could it be defined only in the master
To me, it seems that the first solution is both the easiest to
understand for the user, and the easiest to implement. In the case of
sunterlib, I would also think that this is the most natural, as the
various sub-packages of sunterlib are only loosely coupled. But of
course I'd like your opinion on that since you're the one in charge