On Mon 26 Jan 2004 16:16, Michel Schinz <Michel.Schinz@epfl.ch> writes:
>> - 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
> more?
Simply adding a `text'-directory should be enough, I guess.
>> 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
> course).
Even though I used the data from configure for the wrong purpose, I
still think it's a good thing to have in general. ;-) Maybe
install-lib.scm could provide functions for creating
`config-data.scm.in' template files and also for reading
`config-data.scm' files carefully.
> 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:
>
> (write-to-load-script `((user)
> (load-package (quote (dynamic-externals)))
> ;; ...
> (load ,(absolute-file-name "yp-interfaces.scm"
> yp-scheme-dir))))
>
> 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?
That's a very good idea! Here another point: As Martin pointed out,
the right way for packages with c code for finding the shared module
to load is to look at the .la files generated by libtool. The code
for reading that has to go somewhere, IMHO it makes no sense to
copy/paste that code into every load.scm. Install-lib.scm seems to be
a good place, since then one could include simply by saying:
(write-to-load-script
`((user)
(load-package (quote (dynamic-externals)))
,@libtool-la-reader-code
...))
There is a pretty-printer for scsh (,open pp), may be it's suitable
for layouting the resulting code.
-Eric
--
"Excuse me --- Di Du Du Duuuuh Di Dii --- Huh Weeeheeee" (Albert King)
pgpXJeVWDluri.pgp
Description: PGP signature
|