*LOAD-TRUENAME* and ASDF

[Robert Goldman]

On 8/25/16 Aug 25 -6:55 PM, Jason Miller wrote:
> 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.

Thanks!  That's exactly the work-around I need.

That said, I regret that we have accidentally broke innocent uses of
*load-truename*.

But maybe I can make a FAQ entry for this case.

best,
r

> 
> -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 <rpgoldman at 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*)
>>
>>
>>
>