I finally got some time to work on this and found a complication -
load-source-op logically depends on generated .so files. Currently
process-op produces .so files and load-source-op depends on it. If I
move .c to .so compilation from process-op to compile-op,
load-source-op will have to depend on
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.
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".
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
(asdf/bundl
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 think
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 bund
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 operatio
I figured out my problem: my code was not calling
(enable-deferred-warnings-check).
Sorry for the noise. I was not even aware of
ENABLE-DEFERRED-WARNINGS-CHECK. What is the reason for suppressing
defer-able warnings by default? As far as I understand the distinction between
normal and deferred war
"Robert P. Goldman" writes:
> I cannot replicate this, but this may be a new behavior introduced by
> recent changes to SBCL, and I'm not on the latest release yet.
Very strange. I can reproduce the problem with all the SBCL versions I
have: 1.1.4, 1.1.18, 1.2.4. SBCL 1.2.4 includes the latest ve
Hi,
ASDF does not raise an error, when the SBCL compiler produces
warnings (e.g. "undefined variable", "undefined function").
Example:
test.asd =
(defsystem :test
:version "1.0"
:components ((:file "test")))
test.lisp
(defun foo ()
(+ a b))
==
11 matches
Mail list logo
