Pascal Bourguignon writes:
>So, it seems that postgresql642 needs FFI, but FFI is not compiled or
>integrated before postgresql642.
I doubt FFI is not included in any typical build of CLISP.
>;; Loading file /local/src/clisp-2.30/src/postgresql642/postgresql.fas =
>*** - Incomplete FFI type ConnStatusType is not allowed here.
It looks like a problem when loading a .fas file without loading the =
This hints to a macroexpansion or EVAL-WHEN problem.
I believe you found a bug in DEF-C-ENUM:
(def-c-enum ConnStatusType CONNECTION_OK CONNECTION_BAD)
DEF-C-ENUM ought to produce some
(EVAL-WHEN (LOAD COMPILE EVAL)
(SETF (gethash ',name *c-type-table*) 'int) )
like DEF-C-TYPE does (via ffi::parse-c-type).
Currently, it only binds the type to the name as a side-effect of =
macroexpansion. No wonder it doesn't work with just a .fas file.
Here's how to patch (untested)
(defmacro DEF-C-ENUM (&whole whole name &rest items)
...; from my CLISP 2.28
(push `(DEFCONSTANT ,item ,next-value) forms)
(setq next-value `(1+ ,item)))
`(PROGN ,@(nreverse forms)
(DEF-C-TYPE ,name INT))))
; def-c-type is overkill, but it's regular (no short-circuit =
; and does the right thing:
; (setf (gethash name *c-type-table*) 'int) in all relevant contexts.
>Also, it's surprizing that when you re-configure with a different set
>of modules, those that are not configured in the later run are still
>included (just because their object files are still there).
I believe what is needed is documentation on what the link kit should =
do in the presence of multiple reconfigures (if allowed) and about =
successively building and linking modules.
I cannot help here (Kaz?), I never used the clisp-link script nor tried =
to understand it (script and concept).