common-lisp - 为自定义 C 库分发 CFFI 包装器

对于我自己的问题的答案：似乎既没有事实上的方法（基于对 github asd 文件的搜索），也没有ASDF 最佳实践中的确定方法，尽管有一些想法需要收集从那个文件。

我将把我的实现作为这个用例的建议习语，以及一些可能的替代方案。希望这里的一些 ASDF 专家能够纠正任何误解。

;; Define a makefile as a type of source file for the system
(defclass makefile (source-file) ((type :initform "m")))

;; tell ASDF how to compile it
(defmethod perform ((o load-op) (c makefile)) t)
(defmethod perform ((o compile-op) (c makefile))
  (let* ((lib-dir (system-relative-pathname "cephes" "scipy-cephes"))
         (lib (make-pathname :directory `(:relative ,(namestring lib-dir))
                             :name "libmd"
                             :type #+unix "so" #+(or windows win32) "dll"))
     (built (probe-file (namestring lib))))
    (if built
      (format *error-output* "Library ~S exists, skipping build" lib)
      (format *error-output* "Building ~S~%" lib))
    (unless built
      (run-program (format nil "cd ~S && make" (namestring lib-dir)) :output t))))

(defsystem "cephes"
  :description "Wrapper for the Cephes Mathematical Library"
  :version      (:read-file-form "version.sexp")
  :license "MS-PL"
  :depends-on ("cffi")
  :serial t
  :components ((:module "libmd"
                :components ((:makefile "makefile")))
               (:file "package")
               (:file "init")
               (:file "cephes")))

这在 MS Windows 和 UNIX 上都可以正常工作。添加一个方法perform似乎是github上最常用的方法。

一种替代方法可能是使用build-op，如构建系统中所述。说明

一些系统提供的操作既不加载到当前映像中，也不进行测试。无论系统打算用于哪种操作，您都可以将其用于：

(asdf:make :foobar)

这将调用 build-op，这反过来将取决于系统的 build-operation（如果已定义）或 load-op（如果未定义）。因此，对于希望您加载它们的普通 Lisp 系统，上述将等价于 (asdf:load-system :foobar)，但对于其他 Lisp 系统，例如创建 shell 命令行可执行文件的系统，(asdf:make ...) 将做 Right Thing™，无论 Right Thing™ 是什么。

向我建议，这与构建 C 库的想法相当接近，并且可以很好地映射到使用 makefile 和asdf:make命令的心理模型。虽然我没有找到太多这样的例子，但从技术上讲，我们正在将 C 库加载到现有图像中。

可以重新考虑的另一点是检测现有共享库以避免重建。make如果共享库存在，将避免重新编译，但仍会再次调用链接器。这会导致错误，因为它在使用时无法写入共享库，至少在 MS Windows 上是这样。ASDF 示例使用 Lisp 代码来检测库的存在并避免重新编译，但替代方法可能是使用output-files.

ASDF 文档的目的有点混乱，output-files没有任何例子可以说明他们的意图，但是在创建新操作的手册部分中，我们有：

output-files 如果您的 perform 方法有任何输出，您必须为此函数定义一个方法。让 ASDF 确定执行操作的输出在哪里。

这表明定义共享库（libmd.so 或 libmd.dll）是避免重新编译（如果output-files已经存在）的推荐方法。

cephes/libmd最后，在这种情况下，可以将 C 库视为辅助系统，并将其添加到:depends-on主系统的子句中。有关其他辅助系统的部分演示了以这种方式构建可执行文件，使用build-op. 除了这是构建可执行文件和硬编码“.exe”这一事实之外，它似乎很好地映射到用例上：

要构建可执行文件，请按如下方式定义系统（在这种情况下，它是辅助系统，但也可能是主系统）。您将能够通过评估 (asdf:make :foobar/executable) 创建可执行文件 foobar-command：

(defsystem "foobar/executable"
  :build-operation program-op
  :build-pathname "foobar-command" ;; shell name
  :entry-point "foobar::start-foobar" ;; thunk
  :depends-on ("foobar")
  :components ((:file "main")))

build-pathname 给出了可执行文件的名称；在 Windows 上将自动添加 .exe 类型。

我没有使用这种方法，因为辅助系统看起来与现在的主系统几乎一模一样，但会稍微难以理解。

common-lisp - 为自定义 C 库分发 CFFI 包装器

问题描述

解决方案

推荐阅读