It looks like cffi-wrapper-file does roughly the same thing as protobuf-source-file in https://github.com/brown/protobuf/blob/master/protobuf.asd It runs some program to generate a Lisp file, then compiles and/or loads the Lisp file. Perhaps the approach taken by the protobuf ASDF support can be adapted to CFFI.
On Sat, Aug 1, 2020 at 4:25 AM Faré fahree@gmail.com wrote:
I'm not developing ASDF anymore (unless for hire) but I believe the CFFI toolchain has a new maintainer, who might be willing to devote cycles to that (or at least to merging a patch to CFFI).
Note that if the code that builds stuff and the code that tracks the dependencies disagree, the right solution is to make the dependencies match the actual build, not to make it lie better: make sure that files are attributed as the output-files of the action that creates it, and as the input-files of the other actions.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Due to circumstances beyond your control, you are master of your fate and captain of your soul.
On Fri, Jul 31, 2020 at 1:18 PM Ilya Perminov iperminov@gmail.com wrote:
Hi,
I found a ASDF-related CFFI bug a couple of days ago. Can anyone think of a good way of fixing it?
A method in grovel/asdf.lisp adds output files of process-op to output files of compile-op:
;;; Declare the .o and .so files as compilation outputs, ;;; so they get picked up by bundle operations. #.(when (version<= "3.1.6" (asdf-version)) '(defmethod output-files ((op compile-op) (c wrapper-file)) (destructuring-bind (generated-lisp lib-file c-file o-file) (output-files 'process-op c) (declare (ignore generated-lisp c-file)) (multiple-value-bind (files translatedp) (call-next-method) (values (append files (list lib-file o-file)) translatedp)))))
As a result inputs and outputs of the ops look like this: process-op: input: wrapper-file output: bindings-file.lisp file.c FILE.O FILE.SO
compile-op: input: bindings-file.lisp output: bindings-file.fasl FILE.O FILE.SO
The problem is that process-op generates file.o and file.so before it generates bindings-file.lisp. Thus compile-op gets re-executed all the time, because its output files file.o and file.so are always older than its input file bindings-file.lisp. And an execution of the compile-op does not change anything, because it does not really generate .o and .so. One way to fix it would be to "touch" .o and .so to get the right order of file modification times, but there may be a better way.
CFFI bug report: https://bugs.launchpad.net/cffi/+bug/1889491
Thanks, Ilya