[asdf-devel] Cache? Translations? How to get rid of them?

[Juan Jose Garcia-Ripoll]

On Sun, Mar 14, 2010 at 1:36 AM, Faré <fahree at gmail.com> wrote:

> 1- you want an ASDF operation that dumps some description of
>  things to be loaded.
> 2- you want to use a .asd itself as the output of that operation.
> 3- you want some location-independence in that description.
>
> I presume the role of 2- is so that the result be somewhat interchangeable
> with the original source being packaged? But is that the case?
> Does interchangeability really bring more value than it creates confusion?
>

No, interchangeability means not chance of using the library as it was used.
Not having it means that new ways of loading code and linking it into
executables of libraries should be found. New functions, new operations, new
steps to configure. In other ways, it imposes and additional burden on the
user.

The proof that the current scheme is good is the fact that ECL already
delivers some key libraries in this form. For instance CLX. The result is
that anyone who wants to build a standalone executable including Common
Lisp, CLX and its own custom code may do so using the distributed binary --
no need for sources --. Stumpwm is one user of this, resulting in a really
small executable, 1.5Mb, that just works.


> For instance, XCVB-master (the module that can control XCVB from within
> current Lisp image) uses "manifest" files (or SEXPs) as a delivery
> mechanism
> telling it what files to load -- however, said mechanism is anything but
> location-independent, unless you use logical pathnames.
>

It's your design choice. I believe that distributing together, in the same
directory, the *.ASD file and the binaries, is just fine.


> Now, maybe logical pathnames are exactly the mechanism to use here,
> whether you use ASDF, XCVB-master, or some other homegrown delivery
> target.


No option. What you say is something like for every utility they should cook
up a logical hostname? They would then have to store those logical pathname
definitions in some other file and match the place where they install the
files....

That sounds like imposing an unneeded burden on users of this extension just
because there is one single problem in ASDF (not in the extension), namely
__all physical pathnames gets translated into the cache directory__

We just need a way to selectively deactivate those translations from user
written code. Say, I somebody writes an OUTPUT-FILES she should be able to
tell ASDF that no translations should be applied to those paths. This is
also important for platform independent resources, as it has been discused
in c.l.l.

If you remove this problem somehow, I will stop bothering the mailing list
:-) Really, if that is removed then the extension we cooked should just work
for user code as well.


> > I mean that the set of files should then be installed anywhere the user
> > wants -- as far as it is a path reachable by ASDF and the files remain
> > together, in the same directory. Using logical pathnames is not an option
> > because we can not know where the user wants to have the files.
> >
> I think there's a key constraint I don't understand here.
>

The desire is that people should install things wherever they want. Is that
really a "constraint"?


> Independently from how they are represented in the delivery file,
> how are you supposed to locate the components being delivered?
>

No common file. Just three files, say serve-event.asd, serve-event.fas and
libserve-event.a are stored all together in some directory
/usr/local/lib/asdf/x86-32/serve-event/ and then the user adds the tree
/usr/local/lib/asdf to the set of directories that ASDF scans. Think of a
software distribution that provides serve-event.rpm as a pre-compiled
version of that library. This can be pretty well integrated with ASDF if, as
I say, you just lift the restriction of translating ALL pathnames.


> Are they to be in a path relative to e.g. the truename of the description?
> In some known system path such as /usr/lib?Anywhere in some library search
> path?
> Some combination of the above?
> Note that if a search path is required,
> you'll need some additional facility anyway.


Wherever they want. The point is that we are not allowed to tell people how
they should install their own software. There is no additional facility
needed: they just store the three files together in a search tree taught to
ASDF and I can code the OUTPUT-FILES to resolve the component names
(libserve-event.a, serve-event.fas) based on the location of the *.ASD file.
This can be extended to libraries that carry resources with them -- bitmaps,
binary files, and the like.

If they change the logic of how *.a and *.fas files are located then they
could also write methods for OUTPUT-FILES, but the problem is that right now
the values returned by their methods will always get rewritten by the
pathname translation utility.

Please do not tell me that, given that the tree has to be registered with
ASDF anyway, then they should also add the path to the list of pathnames
that do not get translated. That is a very weak link prone to break.
Furthermore, in the same tree of directories one might want source and
binary versions of ASDF packages.

However, if you want to forget all this blah, blah, blah, it is also ok.
Just remember that what I said above applies: we need a way to write code in
ASDF whose pathnames do not get arbitrarily overwritten. This facility is
seriously needed for ASDF extensibility. Another example. Say, for instance,
that one ASDF extension decides to code temporary files and wants them
stored in /var/tmp so that they get regularly cleaned up by the OS. Again,
either does it push the path in the list of exceptions, or it is fracked.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100314/8b111e58/attachment.html>