On 12 March 2010 00:05, Robert Goldman rpgoldman@sift.info wrote:
I have not been using the output-translations (because my colleagues are still using "classic" asdf), and so I'm not familiar with the configurations. I have gone over the readme, but I was left with (at least) a few questions:
- There's no description of what happens if you have left the
environment variable unset and you don't have any of the magical files. What would happen if you were to do
(asdf:initialize-output-translations)
? What would you get?
I think I hadn't made my mind up when I originally wrote that document. But in my update to the asdf manual, I did specify the current behaviour: all output will be redirected to the user cache in *user-cache*, i.e. '(:home ".cache" "common-lisp" :implementation) i.e. ~/.cache/common-lisp/sbcl-1.0.35.10-linux-x86-64/
[The README says "Indeed, few people use and customize these packages; these people are experts who can trivially adapt to the new configuration." but I don't think that this division of the world into "ASDF by itself" and "Wizards" is accurate. All my colleagues, and several people we have worked with are people who DO use but DO NOT customize ASDF-BINARY-LOCATIONS. That is, they are not Wizards, but they do use A-B-L. So I'm very much interested in what happens to such people.]
Most people will let the default, i.e. this user-cache, or (when using common-lisp-controller) the system cache in '(:root "var" "cache" "common-lisp-controller" :uid :implementation-type) i.e. /var/cache/common-lisp-controller/1000/sbcl/
People who for whatever reason want to disable the cache on a directory can add an entry ("/dont/use/aot/on/this/path/") in their ~/.config/common-lisp/asdf-output-translations.conf.d/10-disable-some-path.conf or disable AOT completely with (:root) in ~/.config/common-lisp/asdf-output-translations.conf.d/00-disable-aot.conf
- Related to the above, can you provide a recipe for getting the same
behavior as ASDF-BINARY-LOCATIONS? A-B-L was quite easy to use --- if you just turned it on, it would split your fasls by implementation type. Is there a simple set of commands --- that can be put entirely into one's lisp init file --- that would replicate this behavior?
AOT is turned on by defaults. To turn it off completely, use (:root) in ~/.config/common-lisp/asdf-output-translations.conf.d/00-disable-aot.conf What other former ABL behaviour do you want me to give examples for?
In a Lisp init file, that would be: (asdf:initialize-output-transations '(:asdf-output-translations (:root) (:ignore-inherited-configuration))) or on Unix, simply: (asdf:initialize-output-transations "/")
- In the readme I see:
(ensure-output-translations) checks whether output translations have been initialized. If not, initialize them. This function will be called before any attempt to operate on a system. If your application wants to override the provided defaults, it will have to use the below function process-output-translations.
but there is no mention of process-output-translations anywhere else in the file.
Oops, some bitrot happened along a refactoring. Fixed.
What I'd like to do:
In general, I'd like to beef up the discussion of "all lisp" configurations of output-translations.
Makes sense.
I ask because although a long-term unix user, I'm not a big fan of the way linux has led to a multiplication of configuration files in different locations. I like to have all my lisp configuration either in my init file (clinit.cl or .sbclrc) or in a file explicitly loaded therefrom. I have a lot of trouble managing the complexity of interacting configuration files, so I simply avoid them. This stands me in good stead with my colleagues --- we stick a file in a project repository, near the root, that configures everything (including the ASDF *central-registry*), using local information (including *load-truename*) and we are happier with that than having to wrangle scattered configurations.
That is sensible. Whatever floats your boat. AtITA, the Makefile for the project I build overrides any user configuration with its own, using suitable environment variables. I could have done it from Lisp instead.
Indeed, I typically have a set of functions, one for each project, that will configure my lisp appropriately. I will usually start a lisp session then, before anything else, execute one of these functions, which will populate ASDF:*central-registry* and set any necessary contextual variables, etc.
The ability to do this is particularly important for my firm because we are a contract research house (a "soft money lab"), and so are often concurrently working on several large systems. We must be able to switch contexts (including sometimes multiple, inconsistent versions of a single library), and having multiple different configuration files scattered around makes project context switches very difficult.
Completely agreed. Once again, these things are actively supported by the current code, and I'm eager to fix any bug. The main problem here is the lack of documentation and examples.
For similar reasons, to the maximum extent possible, I try not to configure with environment variables, because it's difficult to control their flow. E.g., it's difficult to switch from project to project while in a long-running emacs session if unseen environment variables affect the system. Similarly, I find it hard to predict what will happen if I change them in one terminal window --- did that get propagated to that emacs process or not?
I set the environment variables at compile-time from the Makefile through a configuration script, and at run-time from a wrapper script that does the Right Thing (including invoking Lisp for SLIME). So that's 100% controlled. YMMV obviously.
So I'd like to make sure I capture into the manual --- not to the exclusion of all else, of course! --- a set of instructions that will be useful for people like me, who will want to configure everything in their lisp and only the absolute minimum externally.
Totally agreed. Needs to be written totally, though.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] A pretty face is not a passport; it's a visa and it runs out fast.