Let me restart the thread on logical hostnames by explaining a bit better what I have in mind.<br><br>First of all forget ASDF as you are using it: all software requirements and everything that you library needs or might ever need is installed in your system HAS to be there available, properly installed and registered with ASDF, with whatever path registration mechanism you enjoy. What can you do with this? Pretty much nothing else than what you are currently doing: compile-op, load-op, execute, maybe test.<br>
<br>But what if you want to take that software, pack the useful pieces and install it elsewhere? What if you want to produce an executable that your neighbor can use? What if I want to distribute precompiled libraries in the form of Debian or Redhat packages? What if I want to pack an executable and only the essential libraries in a separate directory from the source tree which I am using -- two copies of ASDF with separate configuration? What if I want to prepare a library in the form of a FASL that some user that does not know ASDF and does not want to care about it can load?<br>
<br>The problem is understanding that currently ASDF is used for two different things: BUILDING and EXECUTING software -- if you do not like EXECUTE use LOAD, I do not care -- and they have different requirements.<br><br>
What I am arguing is that EXECUTION does not need ANY dependency on the existence of ASDF and that logical pathname translations are the last ingredient to achieve this decoupling completely.<br><br>My executable or library is not going to need ASDF at all for anything, for
executables are just that: code, and ASDF is nothing but an
specification of how code is bound together with only two bits of
information: an order in which things are loaded and the location of
the files. If ASDF already gave me the information of the location in a
simple form, without any API, like I would have done with a
configuration file (see below), then I do not need anything related to ASDF around.<br><br>Furthermore, when I distribute the software I want it prepared in a way that it can quickly learn where the things it needs reside, without forcing the existence of a valid and properly configured ASDF around. Say I produce a lisp image that contains a system built according to an ASDF specification. Once everything is in memory and dumped, and given that the executable is intelligent enough to know where it resides, why should I ask the user to create a proper ASDF register? More important, why am I going to ask the application I coded to do it itself?<br>
<br>How are these things solved by non-ASDF users (myself one of those until recently). I separate the logic of the program from other issues like location of resources, location of the program, etc. A single file, config.lsp sets up a set of valid and simple logical pathname translations and from there I locate everything else. I then have a builder script that takes the whole package, compiles it and links it (yes, linking, and this is Lisp) and produces a binary  in which the configuration part is executed and the rest of the program can rely on it. And I can say that I tend to write the same configuration file again and again, just changing the names.<br>
<br>I can replace very quickly and efficiently this scheme with an ASDF that creates just *one* logical pathname translation for me. This is what I meant when I said "just the same when built by any other system" -- if I do not build the library with ASDF I can still resort to my hackish configuration file, but I do not have to refactor the whole library for just two dependencies on an API we might cook.<br>
<br>Furthermore, when building other targets, such as binary-format libraries, or standalone executables, it is trivial for ASDF to insert, before any other code, a single compiled item that sets up all the paths in a reasonable and relocatable way -- dependent on the location of the library, following Unix filesystem conventions or just based on the location of an executable --. All this can be easily customized by the people who deliver, without any intervention from the user, who, again, does not need ASDF around. This logic can be reused. And most important, the executable does not need to care about it.<br>
<br>Once we achieve the decoupling from the executable bits from ASDF we are only left with the BUILDING part. Here is where "purity" enters by allowing to separate the bits of the library that are devoted to BUILDING from those that are devoted to EXECUTION, using the :asdf-support keyword I mentioned long ago. One might argue that here logical pathname translations would still have a use, for they would allow the building bits to locate where the sources reside and also to identify where to put whatever they build (binaries, bitmaps, databases, etc). On a first round this may be allowed, but I would say that true building bits should also be generic operations that do not even need to know those details, but just eat the component properties and spit out whatever files they produce.<br>
<br>Then some other details. There has been some advocacy towards allowing arbitrary pathname translations such as "de.weitz:cl-ppcre;version-1-0-1;*.*.*" in the system definition instead of just the logical hostname. I personally dislike this for several reasons. One is that the whole system becomes unverfiable without a very complicated logic. I do not care if you are careful with your own code: what I do not want is that somebody else's ASDF system breaks up mine. Logical hostname conflicts, OTOH, are extremely easy to verify.<br>
<br>The second problem: logical pathnames can not be constructed unless the logical hostname has been defined. Thus the potential argument to a hypothetical :logical-pathname attribute can not be a logical pathname -- only a string. That means ASDF will have to do the parsing of pathnames itself, then defining the logical hostname, verifying whether there are previous translations, adding the new one in a way that works ... That means reimplementing logical pathnames and having something that is too easily broken.<br>
<br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>