I think the machinery the ANS intended to handle this sort of thing (allowing a portable CL application to know at run time where an application was installed long after file compilation or load time) was logical pathnames.
Of course, the detailed behavior of LP translation is so poorly constrained by the ANS that using LPs just squeezes the portability toothpaste from one end of the tube to the other, out through the nozzle, and onto your keyboard. Some of the incomprehensibility and system-dependent behavior of LPs could have been fixed or at least improved if LP matching and translation could have been defined in terms of user-coded functions, but we were tired and didn't think of it at the time. On Sat, Dec 13, 2025 at 10:21 AM Faré <[email protected]> wrote: > There are many issues with using ASDF at runtime: the source may have > moved, been updated ou replaced with an older version, the ASDF > configuration of the user can be wrong, there can be a lot of > subdirectories under the trees registered in the source-registry > causing a long pause when ASDF starts, etc. > > Then again there are just as many issues with requiring a program to > install its data in e.g. data directories from XDG_DATA_DIRS and such. > But if you want to try that, see the xdg- functions in UIOP. > > In the end, the question is whether the target audience is CL > developers staying in their CL world, or regular Unix (or Windows, > macOS) users expecting things under regular paths in their filesystem. > > —♯ƒ • François-René Rideau • Chief Scientist, MuKn.com/fare > “Quality means doing it right when no one is looking.” — Henry Ford > “Morality means doing the right thing when no one is looking.” — Jan > Krepelka > > > On Sat, Dec 13, 2025 at 12:40 PM Marco Antoniotti > <[email protected]> wrote: > > > > ... update. > > > > I bit the bullet and kludged up something like > > > > (defparameter *stuff-dir* (and (asdf:find-system "stuff" nil) > > (asdf:system-source-directory "stuff")) > > > > It works for me. > > > > The asdf:find-system is probably overkill, but better safe than sorry. > > > > MA > > > > > > On Sat, Dec 13, 2025 at 4:16 PM Marco Antoniotti < > [email protected]> wrote: > >> > >> Thanks but no. > >> > >> That would create a dependency from ASDF in the code. > >> > >> MA > >> > >> > >> > >> On Sat, Dec 13, 2025 at 1:50 PM Robert P. Goldman <[email protected]> > wrote: > >>> > >>> ASDF:SYSTEM-RELATIVE-PATHNAME is probably what you want > >>> Sent from my iPhone > >>> > >>> > On Dec 13, 2025, at 06:11, Marco Antoniotti < > [email protected]> wrote: > >>> > > >>> > > >>> > Hi > >>> > > >>> > I am getting old and I get confused. > >>> > > >>> > Here is the thing (a followup to the "wild" ASDF module question). > >>> > > >>> > I am writing something that will have, at run time, a variable > *the-directory-where-stuff-is*. > >>> > > >>> > Now, I want to initialize this variable automagically, with no > "outside" references. I thought I could do something like > >>> > > >>> > (defvar the-directory-where-stuff-is* > >>> > (merge-pathnames (make-pathname :directory '(:relative "stuff") > >>> > :name nil :type nil) > >>> > (make-pathname :name nil :type nil > >>> > :defaults *load-pathname*))) > >>> > > >>> > Alas, ASDF and other things may move the compiled file to a cache > folder, which, in the end misaligns *load-pathname* w.r.t. where "stuff" > actually is (and should be). > >>> > > >>> > This is something that build systems like cmake achieve with the > notion of "source", "install", etc folders. > >>> > > >>> > Any ideas, suggestions, incantations, workarounds, even at the ASDF > level to get this done? > >>> > > >>> > Thanks > >>> > > >>> > > >>> > -- > >>> > Marco Antoniotti > >>> > >> > >> > >> -- > >> Marco Antoniotti, Professor, Director tel. +39 - 02 64 48 79 01 > >> DISCo, University of Milan-Bicocca U14 2043 > http://dcb.disco.unimib.it > >> Viale Sarca 336 > >> I-20126 Milan (MI) ITALY > >> > >> REGAINS: https://regains.disco.unimib.it/ > > > > > > > > -- > > Marco Antoniotti, Professor, Director tel. +39 - 02 64 48 79 01 > > DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it > > Viale Sarca 336 > > I-20126 Milan (MI) ITALY > > > > REGAINS: https://regains.disco.unimib.it/ >
