Организация исходного кода Common Lisp

Я использую quicklisp, который делает"quicklisp" -папку в вашей домашней папке, в которой можно найти папку "локальный проект". Этот содержит txt-файл, в который вы можете вставить URI .файлы asd.

как использовать эту утилиту:

• сделать проект".asd " и " проект-Тест.asd " в папке проекта

(asdf:defsystem :project-name
  :description "description here"
  :version "version here"
  :author "your name here"
  :depends-on (:a
               :list 
               :of
               :dependencie
               :libraries)
  :components ((:file "sourcefileone")
               (:file "sourcefiletwo")))

(asdf:defsystem :project-name-test
  :description "testing"
  ...
  :depends-on (:project-name)
  :components ((:file "sourcefileone-test")
               (:file "sourcefiletwo-test")))

• теперь вставьте URI для этих файлов в вышеупомянутые локальные проекты.txt

• программа параллельна источнику проекта в .lisp-файлы и тестовые вызовы в -test.файлы lisp (*- тест.файлы lisp должны содержать вызов test-execute)

• запустите sbcl или все, что вы используете, а затем используйте (ql:quickload "project-name") или (ql:quickload "project-name-test") в зависимости от того, хотите ли вы просто загрузить спроектировать или протестировать.

единственное, что вам нужно сделать, портируя это в другом месте,-это написать локальные проекты.txt на компьютере, на который копируется проект. После этого ваши колледжи могут зависеть от него, используя asdf-файлы и quickload в любом другом проекте, который они хотят. Для копирования папки проекта вы можете использовать ctr+c / v или, возможно, что-то более сложное, как git.

для тестирования я запрограммировал свой собственный небольшой набор тестов, но я уверен, что есть хорошие там. Более подробную информацию о quicklisp можно найти здесь и о ASDF здесь. Может быть!--37-->этот вопрос может помочь вам, если вы застряли настройки quicklisp.

если Quicklisp установлен, вы можете использовать встроенную функцию Quickproject.

(ql:quickload "quickproject")
(quickproject:make-project "~/src/lisp/swatchblade/"
                         :depends-on '(vecto hunchentoot))

это создает 4 файла:

• пакета.шепелявить!--13-->
• swatchblade.шепелявить!--13-->
• swatchblade.asd
• README.txt

пакета.lisp определяет пространства имен пакетов:

(defpackage #:swatchblade  
(:use #:cl)
  (:shadowing-import-from #:vecto
                          #:with-canvas
                          #:rounded-rectangle
                          #:set-rgb-fill
                          #:save-png-stream))

swatchblade.asd определяет систему / проект, файлы исходного кода, зависимости и т. д.

(asdf:defsystem #:swatchblade 
 :serial t
  :depends-on (#:vecto
               #:hunchentoot
               #:cl-colors)
  :components ((:file "package")
               (:file "swatchblade")))

swatchblade.шепелявость куда идет исходный код.

вы можете загрузить проект через Quicklisp факт так:

* (ql:quickload "swatchblade")
loading output
* (swatchblade:start-web-server :port 8080)
Server started on port 8080.

если вы затем создадите другой проект, который зависит от системы swatchblade:

quickproject:make-project "~/src/lisp/whimsytron/" 
                       :depends-on '(swatchblade))

Что касается тестов, вы можете добавить другое пространство имен в пакет.lisp для ваших тестов:

    (defpackage #:swatchblade-tests  
      (:use #:cl #:swatchblade))

создайте тестовый файл, напишите код и добавьте файл в системное определение:

(asdf:defsystem #:swatchblade 
 :serial t
  :depends-on (#:vecto
               #:hunchentoot
               #:cl-colors)
  :components ((:file "package")
               (:file "swatchblade")
               (:file "swatchglade-tests")))

загрузить swatchblade-тесты пространство имен чтобы провести тесты.

пример проекта с тестами здесь

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

автор Quicklisp, Зак Бин, имеет более подробный пост на используя quickproject.

по предложению Райнера, я предлагаю вам использовать средство определения системы ASDF для определения двух систем, вашей основной системы,фу, и вспомогательная система foo-тесты.

в определении фу system, добавьте спецификацию, которая in-order-to сделать test-op на фу, вам необходимо сделать test-op on foo-тесты. Это гарантирует, что если вы (asdf:test-system "foo") соответствующие тест-системы, с его зависимостями будет загружен, а затем ASDF выполнит тест-op.

Я считаю, что FiveAM является адекватной библиотекой для построения тестов.

выше будет получить все загружено, но теперь вам нужно убедиться, что делает test-op on foo-тесты фактически запускает тесты! Для этого вам нужно добавить метод on PERFORM на TEST-OP и (eql (find-system "foo-tests")). Это PERFORM метод должен вызывать все тесты FiveAM, которые вы определили, и либо успешно, или вызвать ошибку, если тесты не пройдены.

Я сделал дополнение fiveam-tester для ASDF. Я постараюсь сделать его общедоступным.

важно

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

если вы думаете, что будет вред, то вам придется сделать это так:

(defpackage #:sources
  (:use #:cl))

(defpackage #:tests
  (:use #:cl #:lisp-unit)
  (:import-from #:sources))

важная часть -:import-from ваш исходный пакет вместо :useing это.

тогда у вас будет чтобы квалифицировать символы в исходном пакете при их использовании в тестовом пакете. Например, скажем, у вас есть эта функция:

(defun return-true () t)

ваш тест может выглядеть так:

(define-test test-return-true
  "Make sure it works"
  (assert-equal t (sources::return-true)))

важной частью является то, что вы говорите (sources::return-true) а не просто (return-true). То же самое касается символов, таких как 'sym; относятся к нему как 'sources::sym.