Eric Knauel <firstname.lastname@example.org> writes:
> While converting scsh-yp to meet the demands of the packaging
> proposal, I stumpled accross two things:
> - I think packages should be allowed to provide documentation in
> form of pure text files.
I agree. Do you simply mean that I should change the documentation to
specify in which directory it should go, or do you want something
> Here's what I did scsh-yp (see the CVS version) so far: configure
> creates a config-data.scm from a template config-data.scm.in (which
> is basically an alist written to a file with scsh's READ/WRITE).
> Pkg-def.scm then READs that file and the information from that
> list. Uhm, well, probably a hack, comments welcome!
I don't think it's a hack at all, but I think that it could be put in
the installation library since it can be generally useful. I would do
it exactly as you did it, though, using an intermediate file
containing an a-list. (Unless someone knows of a better solution, of
Apart from that, by looking at your pkg-def.scm file, I saw that you
did something that David also does for scx, namely use "sed" to
produce the file "load.scm" from a template.
Generating the "load.scm" file seems to be a fairly common operation,
so some support could also be put in install-lib. My question is how
we should do that.
A first solution would be to adopt your scheme, i.e. use text
substitution. We could do everything from scsh instead of using "sed",
but that's a minor detail.
Another solution is to work at a higher level by taking advantage of
the fact that "load.scm" is a Scheme file. The code in "pkg-def.scm"
could manipulate the contents of "load.scm" as an s-expression, and
then write the result to "load.scm" using a support function.
For example, we could imagine having something like this:
(load-package (quote (dynamic-externals)))
(load ,(absolute-file-name "yp-interfaces.scm"
In other words, we perform the substitution using Scheme's
quasi-quotation instead of textual replacement.
This solution has both advantages and disadvantages. The nice thing is
that we work at a higher-level than raw text, and we don't rely on an
external tool. The main disadvantage I see is that we don't have a way
to easily control the layout of the resulting "load.scm" file. That
is, we cannot easily decide where to put line breaks, and we cannot
include comments for the end-user. But I don't know whether this is
perceived as useful.
What do you think?
(BTW, I was a bit busy since the beginning of the year, but I hope
that I'll be able to restart working on the packaging proposal soon,
in particular to improve the documentation and maybe discuss the whole
thing on c.l.s.scsh).
P.S. I have the feeling there's a problem with the mailing-list <->
newsgroup gateway, or with gmane. The two messages I posted
recently via gmane to the scsh mailing-list didn't appear in the
newsgroup. Could someone who is subscribed to the list tell me
whether the following message appeared there (if it's not the
case, I'll talk with the gmane maintainers):