On Tue Dec 2, 2025 at 8:15 AM CET, Diogo Behrens wrote: >> Normally you should compile both wrapper and .c file together into >> a shared library, like this: >> >> csc foo-wrap.scm foo.c -s -o foo.so -J > > Nice. That is what I was trying to understand. Won't -J create .import.scm as > well overwriting foo.import.scm? > > AFAIU, chicken-crunch -J will create a foo.import.scm, which is used when > building other crunch modules import foo.
That's correct. But we are talking about two different import libraries: Using -J with chicken-crunch will create an import library for the compiled crunch code, so you can import a module into other crunch'ed code or even use syntax definitions from a crunch'ed module in CHICKEN. Using -J for the wrapper on the other hand will wrap a module that is only used for CHICKEN-compiled code, i.e. the wrapper module that uses the crunch'ed code via FFI. > > So foo-wrap.scm csc -J should create foo-wrap.import.scm instead? If you create both import libraries for a crunch-compiled module and the wrapper yes. > Also, if I run the command just like that, it warns that it will overwrite > foo.c. I guess the output .c file is defined based on the name of the final > shared library. Yes, this may be confusing, since we have multiple .c files in case we create a wrapper. > Now when running `csc foo-wrap.scm foo.c -s -J` I get: > > foo-wrap.c:25:23: error: call to undeclared function 'foo'; ISO C99 and > later do not support implicit function declarations > 25 | C_r=C_int_to_num(&C_a,foo()); > | ^ > 1 error generated. > > I think it is not only the name of the procedure that was wrong. But now I > think > I understand the intention of the wrapper. By adding #> int foo(void); #< to > the > wrapper, it compiled and I could run this in csi: > > (import foo-wrap) > (foo) ;; output as expected: 170 > You are right. This is an omission. I wonder if the wrapper should just include the CRUNCH-generated code directly (via "foreign-declare" + "#include"), so you don't have to worry about the separate file. Would this be sufficient? Otherwise we need to create prototypes and parse/process all the type conversion again. > > If I'd understand how the wrapper should look like, I could also try to fix > the > wrapper generation in crunch. But I'd need some hints. The open questions at > the > moment are: > > * can the module in the wrapper have the same name as the crunch module > or should be named differently? I think the wrapper should be named > differently, but might be wrong. I would leave it to the user to name these things as much as possible. Using the same name is certainly prone to confusion, but I have no good solution yet that doesn't somehow restrict users in one or the other way. > * how can the prototypes of the functions defined in foo.c be propagated to > the > wrapper module? Should chicken-crunch create a foo.h alongside foo.c? > Actually, that could be quite handy when embeding crunch in a C program. The simplest solution so far would be (in my opinion) to just #include the generated .c file in the wrapper. I can do that, including the naming bug in the wrapper. But any help is of course appreciated since I'm somewhat slow in reducing my backlog of stuff to do. cheers, felix
