[asdf-devel] output-translations documentation

Robert Goldman rpgoldman at sift.info
Fri Mar 12 05:05:06 UTC 2010


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:

1.  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?

[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.]

2.  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?

3.  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.


What I'd like to do:

In general, I'd like to beef up the discussion of "all lisp"
configurations of output-translations.

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.

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.

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?

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.

cheers,
r




More information about the asdf-devel mailing list