scsh-hackers
[Top] [All Lists]

[Scsh-hackers] Packaging proposal: new version of install-lib

To: scsh-hackers hackers <scsh-hackers@lists.sourceforge.net>
Subject: [Scsh-hackers] Packaging proposal: new version of install-lib
From: Michel Schinz <Michel.Schinz@epfl.ch>
Date: Sun Dec 21 13:49:00 2003
List-id: Discussion among the implementors <scsh-hackers.lists.sourceforge.net>
Sender: scsh-hackers-admin@lists.sourceforge.net
So, I just committed the new version of the installation library, which fixes the problems found by David. It is not 100% backwards-compatible, and since I didn't update the whole documentation yet, some explanations follow.

The option-handling code has been completely rewritten, and it is now possible for packages to specify additional command-line options. This is done through the extensions introduced by David. Here is an example:

(define-package "toto" (1 2)
  ((options . ((with-xft "Compile with Xft support" "<yes/no>" #t #t
                         #f ,parse-boolean ,show-boolean))))
  ... installation code ...)

This specifies an option called "with-xft". An option specification looks as follows:

  (<name> <help-text> <arg-help-text> <required-arg?> <optional-arg?>
   <default> [<parser>] [<unparser>] [<transformer>])

The meanining of these fields is as follows:

<name> (a symbol) is the name of the option, without the initial "--",
<help-text> (a string) describes the option for the user,
<arg-help-text> (a string) describes the option's argument (if any) for the user, <required-arg?> and <optional-arg?> have the same meanining as in srfi 37,
<default> is the default value for the option,
<parser> parses the option, i.e. turns its string representation into its internal value,
<unparser> does the opposite,
<transformer> is a function taking the current value of the option, the value submitted by the user and returning its new value.

By default, <parser> and <unparser> are the identity function, and <transformer> is a function which takes two arguments and return the second (i.e. the current value of the option is simply replaced by the one given).

The parse-boolean and show-boolean functions used above are predefined parsers/unparsers for booleans using the strings "yes" and "no".

This new support for options subsumes the "optional-parts" which were added by David, and I therefore removed explicit support for them (or, to be precise, I didn't re-add it). This is the first source of backward incompatibility, for which I apologise. David should be the only affected, and since he is paid for that, I guess it doesn't matter :-). No, seriously, if someone feels that optional parts *have* to be reintroduced with the same interface as before, I can do it by providing a small layer on top of what we have now.

The second source of incompatibility with the previous version is the way one queries the value of options. There used to be two specific function "is-running-dry?" and "with-optional-part?", and both have been subsumed by the general "get-option-value". This function takes the name of an option, as a symbol, and returns its value.

So instead of "(is-running-dry?)" one now writes "(get-option-value 'dry-run)". This is also the way to get the value of additional options, like the "with-xft" option shown above.

Apart from that, I replaced the "--install-prefix" option by "--dest-dir", which now behaves like DESTDIR. I changed the meaning of the "lib" location, so that it always points to a directory which contains one sub-directory per platform. I made the "host" function available in "pkg-def.scm". And I added an option "--non-shared-only" which asks the installation script to install platform-dependent files only (i.e. the ones in the "lib" location).

As always, comments are welcome. Please notice that I'll be on a computer-free vacation from December 23rd to January 8th, so if you want something to be changed quickly, please tell me as soon as possible.

Thanks,
Michel.



<Prev in Thread] Current Thread [Next in Thread>