[Ecls-list] Back to logical hostnames: decoupling executables from ASDF

[Juan Jose Garcia-Ripoll]

Let me restart the thread on logical hostnames by explaining a bit better
what I have in mind.

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.

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?

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100331/28900308/attachment.html>