Как вы можете заставить ASDF перестать пытаться загрузить несуществующий файл? - PullRequest
Новая
       96

Как вы можете заставить ASDF перестать пытаться загрузить несуществующий файл?

0 голосов
/ 08 июля 2019

В Debian в / usr / lib / sbcl / site-systems была установлена ​​куча cruft, которые не загружались, потому что FASL не соответствовали версии SBCL, которая фактически установлена.

По какой-то причине ни один из этих файлов не был связан с каким-либо пакетом Debian (это старый компьютер, на котором установлена ​​одна и та же установка Debian уже более десяти лет - он находится на Debian Sid).

Я удалял плохие системы по одной, и для большинства из них Quicklisp поступил правильно и скачал версию Quicklisp. Иногда ASDF настаивал на том, что система должна существовать по прежнему пути, но перезапуск SBCL обошел эту проблему.

Но для одной системы ASDF постоянно кэширует местоположение своего файла .asd в каталоге / usr / lib / sbcl / site-systems /. Загрузка этой системы невозможна, потому что ASDF не будет выглядеть нигде, даже после перезапуска SBCL.

Я попытался просмотреть все пути, указанные в различных конфигурационных файлах в / etc / common-lisp. Ни один из этих файлов не содержит ссылки на недостающую библиотеку.

Я прибег к выполнению grep -rli для всех файлов в /usr. Я не ожидаю, что это завершится менее чем за день, и он может ничего не найти, и в этом случае я буду вынужден собрать весь жесткий диск, что может занять целую неделю. Надеюсь, кеш не сжимается, потому что тогда я его никогда не найду.

Кто-нибудь знает, как ASDF сохраняет пути к файлам?

Ответы [ 2 ]

2 голосов
/ 08 июля 2019

После долгих мучительных отладок я обнаружил, что файлы в / usr / lib / sbcl / site-systems / действительно существуют.Это неработающие символические ссылки.

Удаленные файлы находились в похожем пути / usr / lib / sbcl / site /, на который указывали символические ссылки.

Удаление символических ссылок исправляло всеошибки загрузки.

1 голос
/ 12 июля 2019

Несколько идей по устранению неполадок в Quicklisp, особенно, если вы ведете себя странно .:

  • Если вы используете Quicklisp в течение какого-то промежутка времени, вы, вероятно, в конечном итоге будете использовать локальные пакеты, найденные здесь по умолчанию, ~/quicklisp/local-projects Действительна символическая ссылка ваших проектов в этот каталог. Конечно, если вы когда-нибудь переименуете один из своих проектов, не забудьте создать новую символическую ссылку и удалить старую

  • Аналогичным образом, если вы переименуете локальный проект, также удалите системный индекс, который Quicklisp затем воссоздает при следующем запуске: ~/quicklisp/local-projects/system-index.txt Не мешает время от времени удалять его, чтобы сохранить вашу систему свежий.

  • ваши *.fasl файлы также могут устареть, удаление системного кэша заставит quicklisp перекомпилировать все. В системе Ubuntu под управлением SBCL это означало бы удаление содержимого: 

rm -rf ~/.cache/common-lisp
  • Попробуйте обновить клиент Quicklisp 
(ql:update-client)

  • Возможно, потребуется удалить и переустановить сам Quicklisp в ~ / quicklisp. (Возможно непреднамеренное редактирование исходных файлов, когда вы отлаживаете и используете функцию определения поиска Swanks, ломая установленные пакеты, которые раньше работали. Не то, чтобы я когда-либо делал что-то столь же небрежное, как это.)

  • Также не забывайте, что ASDF спускается в каталоги в поисках *.asd файлов. Если у вас есть неправильная структура, которая может привести к хаосу в вашей системе сборки. (См. Мой комментарий выше о регистрации локальных проектов в Quicklisp)

  • Наконец, не забудьте проверить файл инициализации lisp, например, .sbclrc за любые отладочные или быстрые и грязные хаки, которые вы могли оставить там и забыть о них.

Это все вещи, которые работали для меня в то или иное время, надеюсь, я не увековечиваю легенду, и я не умею делать вещи, которые давно исправлены!

...