Correct me if I'm wrong, but the following macro should work: (defmacro lisp-file-truename () (or *compile-file-truename* *load-truename*))
Since minimal compilation requires that macros be expanded at compile-time, compiling a file with an invocation of the above macro should expand it. -Jason On 15:02 Thu 25 Aug , Robert Goldman wrote: > On 8/25/16 Aug 25 -1:08 PM, Robert Goldman wrote: > > On 8/24/16 Aug 24 -4:50 PM, Faré wrote: > >> On Wed, Aug 24, 2016 at 3:09 PM, Robert Goldman <rpgold...@sift.net> wrote: > >>> I just realized that ASDF somewhat breaks *LOAD-TRUENAME*. > >>> > >>> I had some code in a DSL that has an :INCLUDE construct, and that DSL is > >>> being interpreted at load-time. > >>> > >>> The :INCLUDE directive tries to find other lisp files relative to the > >>> current file (the source file that contained the DSL :INCLUDE expression). > >>> > >>> Now, if we were not using ASDF, I would be able to find those files by > >>> merging a name with *load-truename* (and this is how things used to work). > >>> > >>> But ASDF's relocation of the fasls breaks this. > > > > [...snip...] > > > >> Can UIOP:CURRENT-LISP-FILE-PATHNAME help you? > > > > No, I'm afraid not. It returns the same thing that *LOAD-TRUENAME* > > does: the pathname for the fasl file, located in the cache, instead of > > the source file. > > > > CURRENT-LISP-FILE-PATHNAME evaluates to > > > > (or *compile-file-pathname* *load-pathname*) > > > > which means that I still get the pathname of the relocated fasl file, > > instead of the pathname of the lisp source file. > > > > I don't obviously see a way to invert the file translation function, either. > > > > I'm surprised I never noticed this in all these years. > > > > It's not obvious how to fix this, since the idea of having a dynamic > > variable bound (which was my first thought) isn't clearly feasible, > > since the COMPILE-FILE and LOAD aren't in a shared function call scope, > > because of the plan structure. > > > > I suppose one could add something to the PERFORM method for LOAD-OP, but > > when you're performing a LOAD-OP, you aren't even guaranteed that a > > corresponding COMPILE-OP exists (i.e., the process of COMPILE-THEN-LOAD > > could have been overridden). > > Ok, I *believe* that we could change this: > > (defun perform-lisp-load-fasl (o c) > (if-let (fasl (first (input-files o c))) > (load* fasl))) > > into something like > > (defun perform-lisp-load-fasl (o c) > (if-let (fasl (first (input-files o c))) > (let ((*lisp-source-truename* (component-pathnme c)) > (load* fasl))) > > and then export *lisp-source-truename*. > > Not ideal, but I'm having trouble thinking of a good alternative. > > The only other thing I can think of would be to supply a function that > would do: > > (uiop:inverted-file-redirection *load-truename*) > > >
