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

Question

我构建了一个包含自定义 C 代码的库，并考虑了构建共享库作为 ASDF 加载的一部分的最佳方式。 makefile 针对各种操作系统进行了条件化，因此它可以像 uiop:run-program ... 一样简单，但我想我会在这里问一下是否有更标准的习惯用法。

因为 C 代码是特定于此应用程序的，所以它不能通过包管理器使用，必须专门为每个用户的机器构建。我很乐意记录手动构建，但如果我能为用户解决问题，我会的。我注意到 Python 似乎有某种自动方式来为他们的 CFFI 构建库，我想知道是否有用于 CL 的东西。

Answer 1

对于我自己的问题的回答:似乎既没有实际的方法(基于对 github asd 文件的搜索)，也没有在 ASDF best practices 中确定的方法。 , 尽管可以从该文档中收集到一些想法。

我将把我的实现作为这个用例的建议惯用法，以及一些可能的替代方案。希望这里的一些 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，如 building a system 中所述.说明

Some systems offer operations that are neither loading in the currentimage, nor testing. Whichever operation a system is meant to be usedwith, you may use it with:

(asdf:make :foobar)

This will invoke build-op, which in turn will depend on thebuild-operation for the system, if defined, or load-op if not.Therefore, for usual Lisp systems that want you to load them, theabove will be equivalent to (asdf:load-system :foobar), but for otherLisp systems, e.g. one that creates a shell command-line executable,(asdf:make ...) will do the Right Thing™, whatever that Right Thing™is.

对我来说，这与构建 C 库的想法非常接近，并且可以很好地映射到使用 makefile 和 asdf:make 命令的思维模型。虽然我没有发现太多使用这种方法的示例，但从技术上讲，我们正在将 C 库加载到现有图像中。

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

ASDF 文档在output-files 的目的上有点困惑，没有示例可以清楚地说明其意图，但在 creating new operations 的手册部分中我们有:

output-files If your perform method has any output, you must define amethod for this function. for ASDF to determine where the outputs ofperforming operation lie.

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

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

To build an executable, define a system as follows (in this case, it'sa secondary system, but it could also be a primary system). You willbe able to create an executable file foobar-command by evaluating(asdf:make :foobar/executable):

(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")))

The build-pathname gives the name of the executable; a .exe type willbe automatically added on Windows.

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