On 4 Aug 2020, at 12:02, Ilya Perminov wrote:
I think protobuf and CFFI structure their operations in a very similar
way
- process-op is analogous to proto-to-lisp, it takes a "specification"
file
and generates a lisp file and some other files. protobuf generates
lisp(fasl) files only, so it does not need to do anything special to
support bundle operations. CFFI's process-op generates some .o and .so
files that a bundle operation may need. The current implementation
adds .o
and .so files to outputs of compile-op and it causes the problem I
described.
I do not know what methods need to be defined on process-op to make
bundle
operations to pick up its output files. From my very limited
understanding
of ASDF I do not think there is a way to do it. Method
"component-depends-on ((o gather-operation) (s system))" determines
input-files of a bundle-op. The method returns dependencies of one
operation only (e.g. compile-op), but in case of CFFI's wrapper-file
we
need output files of two operations: process-op and compile-op.
I don't claim to understand this process, but wouldn't it be possible
for you to make your own `input-files :around` method for
`gather-operation` that would collect the outputs from the
`process-op`'s and add them to what you want?
Here's the existing definition of what I think is the relevant
`input-files` method:
```
(defmethod input-files ((o gather-operation) (c system))
(unless (eq (bundle-type o) :no-output-file)
(direct-dependency-files
o c :key 'output-files
:test (pathname-type-equal-function (bundle-pathname-type
(gather-type o))))))
```
This invokes `map-direct-dependencies` which invokes the
`component-depends-on` method for `gather-operation` on the system which
... I don't really understand, but I believe it's the `compile-op`'s.
I think it would be easiest to write your own method that collects up
all of the `process-op` outputs, drops any `.lisp` files (which will be
superseded by the `.fasl` files), and adds them to the return value of
`call-next-method`.
If you do that, and drop the `.o` and `.so` files from the
`output-files` of `compile-op`, I think that would get what you want:
you would collect the `.o` and `.so` files from the `process-op`, and
you wouldn't get ASDF trying to regenerate the files when it's not
necessary.
That said, I can think of a simpler, and easier method, and that would
be to override the `operation-done-p` method for the `compile-op` so
that it knows that the `.o` and `.so` files are generated by the
`compile-op`, and only pays attention to the relationship between
`bindings-file.lisp` and `bindings-file.fasl`.
One thing you didn't say was what it means that the compile-op is done
over and over -- is it only compiling the bindings-file, or is it doing
something to the object files? I don't believe it should change the `.o`
and `.so` files, because those are already compiled by `process-op`,
right?
