Thanks for the explanation. process-op does not really need a
generated .so file, only its name. I'll try moving compilation of .c
files to compile-op and see if it causes any problems. It seems it
will be an easy thing to do.
On Tue, Aug 4, 2020 at 6:13 PM Ilya Perminov wrote:
> The files are the same. compile-op does not touch them at all. They
> are just its fake output-files. Is it a good idea to compile a .c to
> .o/.so in a compile-op? Its doc string says ""Operation for compiling
> a Lisp file to a FASL".
I
On 4 Aug 2020, at 17:00, Ilya Perminov wrote:
I think there is a problem with the :around method approach - it is
not safe for an ASDF extension to define methods on ASDF's
operations/components, because other ASDF extensions may want to do
the same thing. Imagine there is CFFI* and I want to
I think there is a problem with the :around method approach - it is
not safe for an ASDF extension to define methods on ASDF's
operations/components, because other ASDF extensions may want to do
the same thing. Imagine there is CFFI* and I want to use both CFFI and
CFFI*.
The files are the same. compile-op does not touch them at all. They
are just its fake output-files. Is it a good idea to compile a .c to
.o/.so in a compile-op? Its doc string says ""Operation for compiling
a Lisp file to a FASL".
On Fri, Jul 31, 2020 at 1:18 PM Ilya Perminov wrote:
> 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
>
Actually, a quick aside: `gather-operation` is an unpleasing name,
since most of our other operation subclasses are named *foo*-`op`.
Is there some way to make `gather-op` a new name, while keeping
`gather-operation` as a (deprecated) alias for the class? Ideally
permitting users' method
On 4 Aug 2020, at 16:18, Ilya Perminov wrote:
The around method will look something like this
```
(defmethod input-files :around ((o asdf/bundle::gather-operation) (c
system))
(unless (eq (asdf/bundle::bundle-type o) :no-output-file)
(append (call-next-method)
The around methed will look something like this
(defmethod input-files :around ((o asdf/bundle::gather-operation) (c system))
(unless (eq (asdf/bundle::bundle-type o) :no-output-file)
(append (call-next-method)
(remove-if-not (asdf/bundle::pathname-type-equal-function
On Tue, Aug 4, 2020 at 12:51 PM Robert Goldman wrote:
> 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?
I
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
On Tue, Aug 4, 2020 at 1:03 PM 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)
>
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
13 matches
Mail list logo
