[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40099: 28.0.50; [feature/native-comp] Different working dir of .eln
bug#40099: 28.0.50; [feature/native-comp] Different working dir of .eln files is not expected by pdf-tools
Wed, 18 Mar 2020 12:59:34 +0000
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Ihor Radchenko <address@hidden> writes:
>> Could I have exact instructions to preproduce it?
> 1. Install pdf-tools and compile .elc
> 2. Run (native-compile-async "/path/to/pdf-tools/" t)
> 3. Restart emacs
> 4. Load pdf-tools and run (pdf-tools-install)
>> I'm not into pdf-tools but I think the trouble could be that its "make
>> build" does something different in terms of compilation that what
>> `native-compile' does. I suspect it's not a load path problem.
> pdf-tools does not even get to the point where it invokes make.
> The backtrace is:
> Debugger entered--Lisp error: (wrong-type-argument (and (not null)
> file-directory) nil build-directory)
> nil nil #f(compiled-function (executable) #<bytecode 0x1442895ca862f2c6>))
> I checked the source code to get a clue where the directory argument is
> coming from. Here is relevant code:
> (defconst pdf-tools-directory
> (or (and load-file-name
> (file-name-directory load-file-name))
> "The directory from where this library was first loaded.")
> The value of pdf-tools-directory is
> It makes sense considering that it takes the value of load-file-name,
> which is probably set to where .eln file is located. However, pdf-tools
> does not expect the location of the loaded file to be different from the
> package dir.
> Hope it helps.
> Best regards,
Great I think the problem is clear, pdf-tools is using `load-file-name'
as a way to obtain `pdf-tools-directory' but this is false assumption
for the eln folder directory we have arranged.
I'm not sure we want or can mitigate this easily but I guess the same
assumption is done in other packages so it's tricky.
Adding Stephane in cc to get an optinion on this.
Thanks for reporting.