Anthony Carrico <acarrico@memebeam.org> writes:
> On Tue, Feb 17, 2004 at 05:04:41PM +0100, Michel Schinz wrote:
>> > Do you think it would be necessary to filter out the particular
>> > options required by each sub-package?
>>
>> I'm afraid I don't really understand what you mean by this.
>
> You propose that the parent-package should take the union of the
> options of all the sub-packages. If sub-package A could take options
> "foo" and "bar", and sub-package B could only take option "bar",
> then should the parent-package avoid passing option "foo" to
> sub-package B?
Ah, now I get it. I think it's fair to have a way to generally
transform options passed to sub-packages, and that's what I just
implemented (and committed).
So now install-lib offers a new function, called install-sub-package,
which has the following profile:
(install-sub-package directory [options-diff])
DIRECTORY is the name of the directory containing the package
definition file (pkg-def.scm) for the sub-package. OPTIONS-DIFF, which
is the empty list by default, specifies a list of "differences" to
apply to the options received by the master package before passing
them on.
Each of these differences can be either a single symbol, which means
that the corresponding option is removed, or a pair (key, value),
which means that this pair replaces all previously-existing values for
the key in the list of options.
That is, if you write something like
(install-sub-package "args-fold" '(prefix
(inactive . #t)
(some-option . "some value")))
then the package(s) in directory "args-fold" will be installed without
prefix (and therefore will fail, but that's just to give an example),
with the "--inactive" option forced to #t, and with "--some-option"
set to "some value".
The current implementation of "install-sub-package" doesn't really
implement solution 1 I proposed, for performance reasons: I didn't
want to have to reload all the installation library on each
sub-package installation, so the package descriptions are loaded in
the current process, i.e. in the context of the master package
installation. This has several consequences, some I don't really like,
for example that all definitions of the master package are visible in
the sub-packages, and the other way around once a sub-package has been
installed. I tried to fork before installing a sub-package, but ran
into strange errors which I'll investigate soon. But anyway, even a
fork wouldn't prevent "pollution" from the master to the sub-packages,
only the other way around. We'll see whether that turns out to be a
problem in practice, but I don't think it will...
I hope this new function will help you for sunterlib.
Michel.
|