*LOAD-TRUENAME* and ASDF

[Robert Goldman]

On 8/25/16 Aug 25 -8:02 PM, Faré wrote:
> Yeah, you may have to call (current-lisp-pathname) in a macro and/or
> in an eval-when.
> 
> What I generally recommend, though, is to save the pathname of the
> system (via system-relative-pathname) and/or the file that you process
> so that you can keep things relative to it.

Right.  My preference is to save the file that is processed, so that I
don't require the part to understand the whole.

best,
r


> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> 
> 
> On Thu, Aug 25, 2016 at 7:55 PM, Jason Miller <jason at milr.com> 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.
>>
>> -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*)
>>>
>>>
>>>
>>