A followup: this behavior stops when I comment out (:cffi-wrapper-file "wrappers" :soname "libosicat”) in osicat’s asd file.
I understand that wrappers are to generate functions from C macros, necessitating a C compilation step to build a dynamic library that is then loaded.
For example in libosicat, the following line appears to turn a C macro into a function
(defwrapper* "s_isreg" ("int" :boolean) ((mode ("mode_t" mode))) "return S_ISREG(mode);”)
Apparently wrappers.lisp becomes wrappers.processed-wrapper-file, which, despite not changing upon reload of osicat system, is recompiled anyway, resulting in a new wrappers.fasl.
The dynamic library resulting from this (libosicat.dylib on OSX) is not rebuilt, however.
In short, :CFFI-WRAPPER-FILE seems to trigger unnecessary recompilation of an intermediate lisp file processed from the original lisp source, but not creation of this intermediate file, nor the recompilation of the dynamic library.
Using the latest git version of CFFI doesn’t seem to help.
On Apr 14, 2020, at 1:06 PM, JTK jetmonk@gmail.com wrote:
Hello,
Sorry if this is the wrong place to ask ...
I’m using the ‘osicat’ package ( https://common-lisp.net/project/osicat/ https://common-lisp.net/project/osicat/ and https://github.com/osicat/osicat https://github.com/osicat/osicat ) in SBCL on OSX.
whenever I do ‘(asdf:load-system “osicat”) it seems to recompile the cffi-grovel-files and their dependencies.
Is this normal, or is there some way to make it behave like asdf usually does, that it recompiles only when a file has changed?
I know that this issue has 3 components (asdf, cffi, and osicat), but I thought I’d first check whether this is an unavoidable feature of using grovel files. If not, I can try to fix osicat.
Here are some of the compilation messages: https://pastebin.com/GKArFCWc https://pastebin.com/GKArFCWc
JK