Rationale: To make asdf easier to use by providing a standard interface for configuring, installing, and removing systems
Details: To facilitate easier configuration, installation, and removal of asdf systems, I propose 2 new operations and 2 new functions be added. The operations would be install-op and remove-op, and the functions would be configure and config-of
These new components would work as defined below:
* New function: configure
(defmethod configure (&rest options) ...)
configure would, given a plist of options, print them to a file in the current directory (which is assumed to contain the asdf system to configure), for example `config.asdf'. If config.asdf already exists, it should be moved to config.asdf.bak before the mew config.asdf is written.
* New operation: install-op
install-op would, given a directory in which `configure' had been run, use the options given to configure to install the system. The options involved would be :sources and :registry . :sources is the pathname of a directory which is to be created, after which the contents of the current directory is copied into the directory named by :sources .
After the files are copied, all .asd files in :sources are linked into the pathname located in :registry.
It is an error to run install-op without first having called configure.
* New function config-get
(defmethod config-get (system config-key &optional default) ...)
config-get will, given a system and config-key retrieve the value of config-key located in the config.asdf file located in the same director as the .asd file of the system (after dereferencing symlinks).
This method is meant so that library/program authors can add additional configure options which the library/program can later access (Ex. a graphics library with an optional #d component could instruct users to pass `:3d t' or `:3d nil' depending on whether they want the 3d component. The user's choice would be accessed through config-get).
The functions will return 2 values, the primary being the result of the lookup or default if the lookup fails, and a secondary which is T if the lookup succeeded and NIL otherwise.
* New operation: remove-op remove-op would undo the operations preformed by install-op, first removing the symlinks in :registry then deleting :sources.
Comments, suggestions, questions, etc. are appreciated.
Krzysztof Drewniak
[P.S. I will not be available between 09/22/2010 and 09/29/2010 due to a vacation resort in Mexico which has an 80% chance of no free Internet]
One thing I think worth considering is the distinction between the configuration that is done at install time and the configuration that is done (by the user) at run time.
This proposal seems to support only installer configuration, not configuration by the person running the program.
Honestly, I'm not convinced that this set of operations meets a general need, but I could be convinced.
I don't like the idea of site-wide installation, because I typically run multiple, not consistent, configurations of CL.
E.g., for one project there is a set of known-stable, but out of date, libraries. For another that is more actively being developed (as opposed to being maintained), I use some of the same libraries in bleeding edge form.
Related to that, this proposal seems tied to the "link farm" style of registry management, which is deprecated as of ASDF 2.
Best, r
On 19 November 2010 15:22, Krzysztof Drewniak krzysdrewniak@gmail.com wrote:
Rationale: To make asdf easier to use by providing a standard interface for configuring, installing, and removing systems
Details: To facilitate easier configuration, installation, and removal of asdf systems, I propose 2 new operations and 2 new functions be added. The operations would be install-op and remove-op, and the functions would be configure and config-of
* New function: configure * New operation: install-op * New function config-get * New operation: remove-op
[...]
1- No one else than yourself will implement this proposal.
2- It's not clear that anyone would use it. What problem are you solving? How does it help?
3- As for precise semantics, how do your operations recurse or not recurse to dependencies?
4- How do you distinguish between fasls compiled with different options.
[P.S. I will not be available between 09/22/2010 and 09/29/2010 due to a vacation resort in Mexico which has an 80% chance of no free Internet]
Your .sig is obsolete.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] "Crash programs fail because they are based on theory that, with nine women pregnant, you can get a baby a month." — Wernher Von Braun, when asked by the US government why tossing scientists at the 'space race' was not helping.