On Thu, Feb 12, 2004 at 10:01:01PM +0100, Michel Schinz wrote:
> 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".
This is option I am thinking about too.
> (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
> detail).
I don't think it is a good idea to copy or link the installation
library in every subdirectory. I'll load or install the installation
library before the others.
> 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.
Yes, basically.
> 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.
Do you think it would be necessary to filter out the particular
options required by each sub-package?
--
Anthony Carrico
|