Где должен быть Quicklisp QUICKLOAD в моем источнике? Никуда? - PullRequest
9 голосов
/ 23 марта 2012

Допустим, я создаю приложение поверх net.aserve и bordeaux-threads.Объявление моего пакета может выглядеть так:

(defpackage :my-package
  (:use :cl :net.aserve :bordeaux-threads)
  (:export …))

Я использую Quicklisp, поэтому я запускаю (ql:quickload "aserve") (ql:quickload "bordeaux-threads") в SLIME перед компиляцией пакета, и все в порядке.

Конечно, завтра яснова запустите SLIME, и я должен не забыть выдать QUICKLOAD s перед компиляцией, в противном случае у меня будут проблемы.

I может поставить что-то вроде

(eval-when (:compile-toplevel)
  (ql:quickload "aserve")
  (ql:quickload "bordeaux-threads"))

в верхней части моего пакета - это то, что я сделал для разработки, - но я чувствую, что не стоит навязывать пользователю менеджер пакетов.

Есть ли лучшая альтернатива

Ответы [ 4 ]

12 голосов
/ 23 марта 2012

В вашем asd-файле вы должны определить зависимость зависимостей следующим образом: ''

(asdf:defsystem #:aserve
 :serial t
 :depends-on (#:hunchentoot :hunchentoot-cgi
           #::bordeaux-threads
           #:parenscript)
 ...)

После этого вам просто нужно (ql: quickload: aserve).

11 голосов
/ 23 марта 2012

Используйте quickproject (доступно через (ql:quickload :quickproject)), чтобы создать систему для вашего приложения. Как описано в z_axis, вы можете заполнить список зависимостей в объявлении defsystem (если вы пропустили его при вызове quickproject:make-project).

Если вы создаете новый проект по пути local-projects вашей установки Quicklisp, вы также можете быстро загрузить свой проект (даже если он еще не является частью дистрибутива Quicklisp). Быстрая загрузка вашего проекта, разумеется, загрузит зависимости (если они являются частью дистрибутива Quicklisp), а затем загрузит их.

2 голосов
/ 29 мая 2013

Если вы вообще не хотите включать вызов quicklisp в развернутый исходный код, отделите файл определения системы quickproject от остальной части источника.

В верхней части источника, перед вызовом defpackage, добавьте необходимые (require ...) для зависимостей вашего пакета. Это гарантирует, что эти пакеты lisp загружаются (каким-либо образом) перед продолжением, но не указывает, как эти пакеты загружаются. Их можно загрузить, выполнив вызов ql:quickload :my-package (используя quickproject), который сначала загрузит зависимости, а затем выполнит вызовы require при загрузке источника. Или, возможно, пользователь может загрузить источник напрямую (без вызова ql:quickload), и зависимости будут загружены во время вызова require, если эти зависимости можно найти в *module-search-path*. Этот метод, как вы сказали, позволит конечному пользователю использовать любой инструмент для сборки, который он / она хочет загрузить ваш источник.

После экспериментов с этим в течение нескольких минут кажется, что quicklisp фиксирует вызов функции require, так что если установлен quicklisp и вызывается (require :bordeaux-threads) например, lisp будет использовать quicklisp для загрузки и установки этой зависимости. Это очень хорошая функция (IMO), потому что она позволяет стандартной функции require Common Lisp выступать в качестве интерфейсного уровня и абстрагирует конкретный инструмент сборки, используемый для удовлетворения зависимости. Quicklisp может зафиксировать нужное, asdf защёлкнуть (IIRC) и т. Д.

Таким образом, чтобы ответить на ваш вопрос, вызовы quicklisp не должны идти куда-либо в развернутом исходном коде, и следует использовать requires, чтобы гарантировать, что зависимости загружаются до оценки файла определения пакета. Если кто-то установил quicklisp перед загрузкой файла определения пакета, эти требования будут удовлетворены с помощью quicklisp для загрузки и установки зависимостей. Если кто-то установил asdf, эти зависимости будут удовлетворены этим инструментом сборки. И если кто-то уже установил зависимости (используя другую технику), то требования будут просто пропущены.

2 голосов
/ 21 мая 2013

У меня был точно такой же вопрос, и я согласен, что не должен навязывать менеджер пакетов пользователю. До времени Quicklisp я использовал clbuild, и он помещает все файлы .asd в каталог systems /. Пока каталог `systems / 'находится в формате asdf: central-registry , можно просто (требовать a-package), по крайней мере, в SBCL и CCL, загрузить все соответствующие пакеты. Новый clbuild2 сохраняет эту функцию, если вы выполняете установку из восходящего потока, и его встроенный quicklisp учитывает отдельно установленные пакеты из исходящих, но установленные пакеты quicklisp больше не предоставляют свои файлы .asd.

Таким образом, мое решение - написать сценарий оболочки, который сканирует все установленные пакеты quicklisp, обычно в каталоге dists / quicklisp / software /, и связывает все файлы .asd в центральном месте. Таким образом, не нужно загружать quicklisp в образ cl, если нужно использовать только установленные quicklisp пакеты. Я надеюсь, что quicklisp сможет доставить эту функцию по умолчанию.

...