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