cl-autowrap
cl-autowrap copied to clipboard
rpav
Wrapping my head around autoharp
Hi
I know I am missing something...
So: I installed c2ffi and it appears to be working as advertised. Next I am trying to see how c-autowrap works.
Here is my .h file (straight from the README):
// -*- Mode: C++ -*-
/* test.h - abbreviated from example */
typedef struct foo {
int a, b;
char c[3];
struct {
unsigned int b0 : 2, b1 : 3;
struct {
char x, y;
} s;
} x[2];
} foo_t;
foo_t* get_foo();
// foo_t* get_foo(int, int);
void free_foo(foo_t *foo);
int* get_int();
Here is my CL file:
;;;; -*- Mode: Lisp -*-
(in-package "CL-AUTOWRAP-TESTS")
(eval-when (:load-toplevel :compile-toplevel :execute)
(setf autowrap:*c2ffi-program*
"/Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi")
)
(autowrap:c-include "cl-autowrap-test.h")
If I load this file, I obtain a bunch of .spec files, which contain only [ ]. Nothing else appears to be generated. This is the transcript:
CL-USER 8 > (load "cl-autowrap-test.lisp")
; Loading text file /Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.lisp
; Total of 0 compile-time skipped definitions
; Total of 0 compile-time missing entities
; Total of 0 load-time skipped definitions
; Total of 0 load-time missing entities
#P"/Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.lisp"
CL-USER 9 > (apropos "GET-FOO")
CL-USER 10 >
I am obviously missing something, but what?
Help please
Thank you
Marco
Well, if the spec files are blank that's definitely a problem; you say c2ffi is "working as advertised" so I assume that means it generates reasonable results when you run it on the same .h file?
I'm not sure where you're running this but c2ffi should generate some output if there are issues. Check inferior-lisp buffers or terminal windows, though I can't imagine why it would end up there. You can also use :trace-c2ffi t to generate slightly more output and keep around the temporary files for you to inspect.
(For more than testing, you should definitely not setf *c2ffi-program* of course. Ideally just throw it in ~/bin or something and put that in your PATH.)
An easy thing to do is also just open the autowrap file and like M-x slime-macroexpand-1 the (autowrap ...) form, and watch the output in the repl or whatnot. You should be able to delete .spec files and cause them to be regenerated that way as well.
Hi,
this is what I get from c2ffi on the file:
bash-3.2$ ./build/bin/c2ffi ../tests/test.cpp
c2ffi warning: Unhandled environment: '' for triple ''
[
{ "tag": "const", "name": "BAR", "ns": 0, "location": "../tests/test.cpp:5:11", "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 }, "value": 14 },
{ "tag": "struct", "ns": 0, "name": "my_point", "id": 1, "location": "../tests/test.cpp:7:16", "bit-size": 544, "bit-alignment": 32, "parents": [], "fields": [{ "tag": "field", "name": "x", "bit-offset": 0, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }, { "tag": "field", "name": "y", "bit-offset": 32, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }, { "tag": "field", "name": "odd_value", "bit-offset": 64, "bit-size": 480, "bit-alignment": 32, "type": { "tag": ":array", "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 }, "size": 15 } }], "methods": [] },
{ "tag": "typedef", "ns": 0, "name": "my_point_t", "location": "../tests/test.cpp:11:3", "type": { "tag": ":struct", "name": "my_point", "id": 1 } },
{ "tag": "enum", "ns": 0, "name": "some_values", "id": 0, "location": "../tests/test.cpp:13:6", "fields": [{ "tag": "field", "name": "a_value", "value": 0 }, { "tag": "field", "name": "another_value", "value": 1 }, { "tag": "field", "name": "yet_another_value", "value": 2 }] },
{ "tag": "function", "name": "do_something", "ns": 0, "location": "../tests/test.cpp:19:6", "variadic": false, "inline": false, "storage-class": "none", "parameters": [{ "tag": "parameter", "name": "p", "type": { "tag": ":pointer", "type": { "tag": "my_point_t" } } }, { "tag": "parameter", "name": "x", "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }, { "tag": "parameter", "name": "y", "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }], "return-type": { "tag": ":void" } }
]
This is why I am saying that it seems to be working ok. You tell me.
This is the suspicious macro expansion that I get. Please note that (1) I am not using slime and (2) I am not using SBCL. I expect tools that do not use deep and dark OS dependencies to work on every implementation.
----
(IN-PACKAGE "CL-AUTOWRAP-TESTS")
(PROGN
(EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
(SETF AUTOWRAP::*FAILED-WRAPS* NIL)
(SETF AUTOWRAP::*MUTE-REPORTING-P* NIL)
(AUTOWRAP::WITH-ANONYMOUS-INDEXING)
(AUTOWRAP::COMPILE-TIME-REPORT-WRAP-FAILURES)
NIL
NIL
NIL
NIL
NIL
(SETF AUTOWRAP::*MUTE-REPORTING-P* NIL))
(LET ((AUTOWRAP::*MUTE-REPORTING-P* NIL))
(EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE)
(AUTOWRAP::REPORT-WRAP-FAILURES 'AUTOWRAP::LOAD-TIME *STANDARD-OUTPUT*)
(AUTOWRAP::CLEAR-WRAP-FAILURES))))
---- Done ----
The expansion looks very strange. Have you tested cl-autowrap on LW?
Cheers MA
I have not tested in LispWorks, but unless trivial-features doesn't report correctly I'm not sure why this wouldn't work in principle. (Load autowrap and see what (autowrap::local-arch) says.)
The macroexpansion is blank because the .spec generated are blank; fix this and you should fix this problem, at least. Try passing :trace-c2ffi t to your c-include and note what the invocation of c2ffi says. I can only imagine it's encountering a blank file or something.
Note this also uses uiop for part of this process, and creates some temporary files; assuming that works in LW as well.
Ok. Something is amiss.
Here is a transcript (with some functions TRACEd) of what happens in an empty directory. If you run it a second time, c2ffi does not get run as the spec file is already present (and empty).
CL-USER 21 > (load "cl-autowrap-test.lisp")
; Loading text file /Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.lisp
0 AUTOWRAP::ENSURE-LOCAL-SPEC > ...
>> AUTOWRAP::NAME : "cl-autowrap-test.h"
>> AUTOWRAP::SPEC-PATH : #P""
>> AUTOWRAP::ARCH-EXCLUDES : NIL
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::VERSION : NIL
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.i686-apple-darwin9"
>> AUTOWRAP::ARCH : "i686-apple-darwin9"
>> AUTOWRAP::SYSINCLUDES : NIL
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp2WDZX03L.tmp -A i686-apple-darwin9
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp81CU61X.tmp -o cl-autowrap-test.i686-apple-darwin9.spec -A i686-apple-darwin9
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.i686-pc-linux-gnu"
>> AUTOWRAP::ARCH : "i686-pc-linux-gnu"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpQGO1KSUQ.tmp -A i686-pc-linux-gnu
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpUD9RK7BL.tmp -o cl-autowrap-test.i686-pc-linux-gnu.spec -A i686-pc-linux-gnu
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.x86_64-pc-linux-gnu"
>> AUTOWRAP::ARCH : "x86_64-pc-linux-gnu"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp3J5KEEWK.tmp -A x86_64-pc-linux-gnu
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpOOWBIVB0.tmp -o cl-autowrap-test.x86_64-pc-linux-gnu.spec -A x86_64-pc-linux-gnu
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.i686-pc-windows-msvc"
>> AUTOWRAP::ARCH : "i686-pc-windows-msvc"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpQRKRGFO4.tmp -A i686-pc-windows-msvc
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpGP5B1VAW.tmp -o cl-autowrap-test.i686-pc-windows-msvc.spec -A i686-pc-windows-msvc
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.x86_64-pc-windows-msvc"
>> AUTOWRAP::ARCH : "x86_64-pc-windows-msvc"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpQQECTRK2.tmp -A x86_64-pc-windows-msvc
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpT3WFC692.tmp -o cl-autowrap-test.x86_64-pc-windows-msvc.spec -A x86_64-pc-windows-msvc
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.x86_64-apple-darwin9"
>> AUTOWRAP::ARCH : "x86_64-apple-darwin9"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpV78XXNHS.tmp -A x86_64-apple-darwin9
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpAZ2YQA8R.tmp -o cl-autowrap-test.x86_64-apple-darwin9.spec -A x86_64-apple-darwin9
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.i386-unknown-freebsd"
>> AUTOWRAP::ARCH : "i386-unknown-freebsd"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpW1JJZ8VY.tmp -A i386-unknown-freebsd
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpT2S0T5QA.tmp -o cl-autowrap-test.i386-unknown-freebsd.spec -A i386-unknown-freebsd
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.x86_64-unknown-freebsd"
>> AUTOWRAP::ARCH : "x86_64-unknown-freebsd"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp85L74WA1.tmp -A x86_64-unknown-freebsd
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpG8BAHX2P.tmp -o cl-autowrap-test.x86_64-unknown-freebsd.spec -A x86_64-unknown-freebsd
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
1 AUTOWRAP::RUN-C2FFI > ...
>> AUTOWRAP::INPUT-FILE : "cl-autowrap-test.h"
>> AUTOWRAP::OUTPUT-BASENAME : "cl-autowrap-test.arm-pc-linux-gnu"
>> AUTOWRAP::ARCH : "arm-pc-linux-gnu"
>> AUTOWRAP::SYSINCLUDES : NIL
>> AUTOWRAP::IGNORE-ERROR-STATUS : T
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpVUXUYE98.tmp -A arm-pc-linux-gnu
; Invoking: /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp1SW081OC.tmp -o cl-autowrap-test.arm-pc-linux-gnu.spec -A arm-pc-linux-gnu
1 AUTOWRAP::RUN-C2FFI < ...
<< VALUE-0 : T
0 AUTOWRAP::ENSURE-LOCAL-SPEC < ...
<< VALUE-0 : #P"cl-autowrap-test.i686-apple-darwin9.spec"
0 AUTOWRAP::READ-PARSE-FORMS > ...
>> AUTOWRAP::IN-SPEC : #<STREAM::LATIN-1-FILE-STREAM /Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.i686-apple-darwin9.spec>
>> AUTOWRAP::EXCLUDE-DEFINITIONS : NIL
>> AUTOWRAP::EXCLUDE-SOURCES : NIL
>> AUTOWRAP::INCLUDE-DEFINITIONS : NIL
>> AUTOWRAP::INCLUDE-SOURCES : NIL
0 AUTOWRAP::READ-PARSE-FORMS < ...
<< VALUE-0 : NIL
; Total of 0 compile-time skipped definitions
; Total of 0 compile-time missing entities
; Total of 0 load-time skipped definitions
; Total of 0 load-time missing entities
#P"/Users/marcoxa/Projects/Lang/CL/tests/cl-autowrap/cl-autowrap-test.lisp"
CL-USER 22 >
The temp files that appear in the folder /var/folders/... are empty.
What gives?
Cheers
MA
And here is some smoke:
bash-3.2$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M zot.tmp -A i686-apple-darwin9
c2ffi warning: Unhandled environment: '' for triple 'i686-apple-darwin9'
The file zot.tmp is empty.
Cheers
MA
OK, I get this message even on 3.7. I'll need to look into what the new target triple for OSX is. However, I don't think this is the issue; in your case zot.tmp being empty seems right since there are no #defines in your header.
Autowrap should generate a header file which includes both the original .h you requested as well as the (possibly blank) macro header. If you're using trace, you should first check that this file is created correctly (I believe it's the file specified in the second invocation). Then try running c2ffi on the file yourself, with the same parameters.
Ok. I understand why the zot.h can be empty. I also see the other .h file with the includes. However, I do not see other c2ffi output.
This is what happens if I add a #define in the .h file.
bash-3.2$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h -D null -M zot.tmp -A i686-apple-darwin9
c2ffi warning: Unhandled environment: '' for triple 'i686-apple-darwin9'
bash-3.2$ ls -la
total 32
drwxr-xr-x 6 marcoxa staff 204 Jun 10 14:29 .
drwxr-xr-x 7 marcoxa staff 238 Jun 8 13:27 ..
-rw-r--r-- 1 marcoxa staff 319 Jun 10 14:29 cl-autowrap-test.h
-rw-r--r-- 1 marcoxa staff 282 Jun 9 21:37 cl-autowrap-test.lisp
-rw-r--r-- 1 marcoxa staff 267 Jun 9 15:59 cl-autowrap-test.lisp~
-rw-r--r-- 1 marcoxa staff 28 Jun 10 14:29 zot.tmp
bash-3.2$ cat zot.tmp
const long __c2ffi_FT = FT;
bash-3.2$
However, if I run the plain c2ffi I get the following:
bash-3.2$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi cl-autowrap-test.h
c2ffi warning: Unhandled environment: '' for triple ''
[
{ "tag": "struct", "ns": 0, "name": "foo", "id": 0, "location": "cl-autowrap-test.h:7:16", "bit-size": 160, "bit-alignment": 32, "fields": [{ "tag": "field", "name": "a", "bit-offset": 0, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }, { "tag": "field", "name": "b", "bit-offset": 32, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } }, { "tag": "field", "name": "c", "bit-offset": 64, "bit-size": 24, "bit-alignment": 8, "type": { "tag": ":array", "type": { "tag": ":char", "bit-size": 8, "bit-alignment": 8 }, "size": 3 } }, { "tag": "field", "name": "x", "bit-offset": 96, "bit-size": 64, "bit-alignment": 32, "type": { "tag": ":array", "type": { "tag": "struct", "ns": 0, "name": "", "id": 1, "location": "cl-autowrap-test.h:11:3", "bit-size": 32, "bit-alignment": 32, "fields": [{ "tag": "field", "name": "b0", "bit-offset": 0, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":bitfield", "width": 2, "type": { "tag": ":unsigned-int", "bit-size": 32, "bit-alignment": 32 } } }, { "tag": "field", "name": "b1", "bit-offset": 2, "bit-size": 32, "bit-alignment": 32, "type": { "tag": ":bitfield", "width": 3, "type": { "tag": ":unsigned-int", "bit-size": 32, "bit-alignment": 32 } } }, { "tag": "field", "name": "s", "bit-offset": 8, "bit-size": 16, "bit-alignment": 8, "type": { "tag": "struct", "ns": 0, "name": "", "id": 2, "location": "cl-autowrap-test.h:14:5", "bit-size": 16, "bit-alignment": 8, "fields": [{ "tag": "field", "name": "x", "bit-offset": 0, "bit-size": 8, "bit-alignment": 8, "type": { "tag": ":char", "bit-size": 8, "bit-alignment": 8 } }, { "tag": "field", "name": "y", "bit-offset": 8, "bit-size": 8, "bit-alignment": 8, "type": { "tag": ":char", "bit-size": 8, "bit-alignment": 8 } }] } }] }, "size": 2 } }] },
{ "tag": "typedef", "ns": 0, "name": "foo_t", "location": "cl-autowrap-test.h:18:3", "type": { "tag": ":struct", "name": "foo", "id": 3 } },
{ "tag": "function", "name": "get_foo", "ns": 0, "location": "cl-autowrap-test.h:20:8", "variadic": false, "inline": false, "storage-class": "none", "parameters": [], "return-type": { "tag": ":pointer", "type": { "tag": "foo_t" } } },
{ "tag": "function", "name": "free_foo", "ns": 0, "location": "cl-autowrap-test.h:22:6", "variadic": false, "inline": false, "storage-class": "none", "parameters": [{ "tag": "parameter", "name": "foo", "type": { "tag": ":pointer", "type": { "tag": "foo_t" } } }], "return-type": { "tag": ":void" } },
{ "tag": "function", "name": "get_int", "ns": 0, "location": "cl-autowrap-test.h:23:6", "variadic": false, "inline": false, "storage-class": "none", "parameters": [], "return-type": { "tag": ":pointer", "type": { "tag": ":int", "bit-size": 32, "bit-alignment": 32 } } }
]
Which seems fine to me AFAIU.
Cheers
Marco
"However, I do not see other c2ffi output."
It seems important to find this, e.g. /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpG8BAHX2P.tmp randomly from your output should exist. (Perhaps temporary files don't outlive their process on OSX? not sure.) In any case seeing what's going on there should at least confirm that autowrap is in fact writing something to a file somewhere.
More likely it's not, for some reason (the newer uiop stuff?) ... this would explain the blank spec files. The temp gets created, nothing gets written, c2ffi runs on a blank file, you get blank specs. There is no error because everything was technically where it should be, though why nothing gets written is of course questionable.
The files are there but they are empty. I get the .h with the two #include (I suppose for each triple) but the included file (the second) is empty.
I believe the problem is exactly that nothing gets written. Couldn't you just get rid of UIOP? You are only using it to generate the temp files, aren't you?
MA
"The files are there but they are empty."
"I get the .h with the two #include"
...these are mutually exclusive? If you have a file with the two #include, that's what you need. But if they're blank, then you shouldn't have any #include at all. The second file may be blank (and will if your header lacks any #defines).
Try running the second c2ffi call in the output, e.g.:
$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp81CU61X.tmp -o cl-autowrap-test.i686-apple-darwin9.spec -A i686-apple-darwin9
Now I get an error.
bash-3.2$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp81CU61X.tmp -o `pwd`/cl-autowrap-test.i686-apple-darwin9.spec -A i686-apple-darwin9
c2ffi warning: Unhandled environment: '' for triple 'i686-apple-darwin9'
/var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmp81CU61X.tmp:1:10: fatal error: 'cl-autowrap-test.h' file not found
#include "cl-autowrap-test.h"
^
Heh. Are you running this in the same directory as this file? Also, you may need to specify '.' as an include path. I thought that was a clang default though.
Also if this happens during autowrap's run, your output should show any c2ffi error output...
Ok. Looks like adding manually the -I . to c2ffi is part of the magic incantation.
Here is the transcript:
bash-3.2$ /Users/marcoxa/Projects/Software/c2ffi/c2ffi/build/bin/c2ffi \
> /var/folders/l4/b71hhwhj3f375fqgpw1r_f8c0000gp/T/tmpP8PIUX9B.tmp \
> -o cl-autowrap-test.i686-apple-darwin9.spec \
> -I . \
> -A i686-apple-darwin9
c2ffi warning: Unhandled environment: '' for triple 'i686-apple-darwin9'
bash-3.2$
The resulting output file now contains the (expected?) c2ffi JSON output.
Is there a way to tell c-include to add a -I <dir>?
I have encoutered same problem, the output spec files only contains const. I'd like to share my experience here, in case someone need it.
My Solution
And solve the problem by specifing absolute path to c-include.
Replace (c-include #P"xxx.h") with (c-include #P"/Users/xxxxxx/xxxx/xxxxx/xxx.h")
Why
By reading autowrap/c2ffi.lisp run-c2ffi
-
c2ffi input.h -D null -M tmp-macro-file.c ...to generate only macro content totmp-macro-file.c - create another
tmp-file.c, and includeinput.handtmp-macro-file.cby#include ".." -
c2ffi tmp-file.c ...to generate the final output
So if we use relative path for input header, what's in tmp-file.c could be #include "header/input.h"
it's unclear for a tmp file that includes relative path header.
And it seems that c2ffi recognize tmp-file.c's location as current directory, so it wont find our input.h
Suggestion
- Maybe we could add some document that suggest user to use absolute path for
c-include - Maybe we could add some logic that expand input file into absolute path
