Anthony Carrico <acarrico@memebeam.org> writes:
[...]
> I guess the only way to do this would be to load the sub-package and
> then to scan the extensions in the sub-packages' *packages*, and
> then to remove any options that aren't asked for when installing
> each package, and warn about any options that are never asked for.
>
> Like I said above, It probably isn't worth doing this kind of
> thing. I'm sorry to dwell on it.
Ok, I see what you had in mind. It could be doable, but if you think
that it isn't worth the trouble, I'll be happy to agree with you :-).
> Anyway... I think I found a bug:
>
> When my top-level pkg-def.scm uses install-sub-package like this:
>
> pkg-def.scm:
> (install-sub-package "s48/args-fold")
>
> I get an error. I think the error is that install-sub-package
> references (fluid *options-values*) which isn't set yet. How is this
> supposed to work?
Ah yes, it's just that an "install-sub-package" call, like all
"install-*" calls, must appear inside of the body of a
"define-package" form. That is, your main pkg-def.scm should look like
this:
(define-package "sunterlib" (1 2 3) ()
(install-sub-package "s48/args-fold"))
The reason for this is that installation proceeds in the following
steps:
1. the file pkg-def.scm in the current directory is loaded (with
(load)), which, as a side effect, defines a package,
2. the options of the package defined in pkg-def.scm are gathered, to
create the "usage" message and to know how to parse the command
line,
3. the command line is parsed,
4. the installation statements of the packages are evaluated.
(Note that, with the current implementation, it is possible to define
more than one package in a single "pkg-def.scm" file. I ignored this
above and always talked about "a package" so as not to confuse
things.)
With the current way of doing things, sub-packages are installed at
step 4, and that's why they cannot communicate their options to the
master package(s). By the time these options are known, it's too late.
The error you get above is due to the fact that, since you placed the
"install-sub-package" statement at the top-level of your "pkg-def.scm"
file, it gets evaluated at step 1. That's too early, as the
command-line has not been parsed yet.
- * -
Writing all this down makes me realise that I might have misunderstood
your original proposal. In your first mail about sub-packages, you
said that you had tried to load the "pkg-def.scm" files of
sub-packages directly in the master "pkg-def.scm". I think this could
be a very good and easy way to have sub-packages *if* the sub-packages
are loaded in step 1 (and I think that's what you proposed, in fact,
while I thought you wanted that to happen in step 4).
If we do that, then I think that indeed the solution can be as simple
as associating a current directory with every package definition, as
you originally suggested. Basically, you would write a master
"pkg-def.scm" which would consist of several calls to (a new function)
"load-package-in", to load sub-packages, and then maybe a single
"define-package" for the master package (if that's needed). Something
like this:
(load-package-in "s48/args-fold")
(load-package-in "s48/intsets")
(define-package "sunterlib" (1 2 3) ()
...)
So, I just implemented that as it was trivial, and I will commit it
right away. If you find that this way of doing things is better than
using "install-sub-package", I'll remove the latter in a future
version.
As shown above the function I added is called "load-package-in", takes
a directory name as argument, and loads the file "pkg-def.scm"
contained in that directory. Calls to this function must appear
outside of a define-package form.
Michel.
|