autowrap sometimes forgets to parse the original file

[MustacheMerlin]

So, I found an interesting issue just now, it's probably my fault for just doing things the "dumb way," but might still be worth a look.

Basically, the short version: because the run-c2ffi function moves everything to the /tmp directory, it can happen that the header you originally wanted to parse is off the include path. The end result is that c2ffi can't find and include the original header, silently skips it, and only outputs the c macros from the preprocessor step. I eventually figured out what was going on and worked around it by manually adding my project directory to sysincludes.

Long version:
As suggested in the readme, I have a barebones asdf system with two files in it:
includes.h - a header file that #includes all the headers I want to parse
#include "vulkan.h"
wrapper.lisp - where I do the c-include.
(c-include "includes.h" :sysincludes '("path/to/header/files"))

first, c2ffi gets run on includes.h to get the preprocessor macros. It puts that information in a tmp (eg. tmp12345) file, and creates a temporary header that includes includes.h and tmp12345. It looks like this:
#include "includes.h" #include "tmp12345"

Next, and this is where it fails, it runs c2ffi again on the temporary header to get the real parse output. Since the temporary header is in /tmp, operations have moved there. It includes tmp12345 just fine since it's also in the /tmp directory. Then it tries to find includes.h, and can't find it because includes.h is isn't on the include path and we're no longer in that directory. c2ffi rightly throws an error, but cl-autowrap silently discards it and carries on, completely oblivious that it's missed the entire header file. Only the definitions from the first preprocessor pass make it through to the final .spec files, the main pass was useless.

Proposed solution: have c-include append the header's directory to the end of sysincludes by default, so that c2ffi will always still be able to find it once its moved to /tmp.

I'm obviously super new at this, so I can't forsee if there are any consequences to doing that, and I'm pretty sure I did something wrong setting everything up that caused me to run into this issue at all. I figured it couldn't hurt to document my findings though, in case anyone else runs into the same problem. Thanks for your time and this awesome tool, have a wonderful day!

[rpav]

This seems weird, the temp file(s) should be unique per run and deleted unless you specify otherwise... but I haven't looked at this in awhile and forget what actually happens.

That said with autowrap a fair bit is up to you to check c2ffi's error output and make sure everything ran sufficiently correctly in any case; it's perfectly possible to get reasonable looking output but be missing a few definitions because some particular header was not found. And this may even be ok for some purposes.

[rpav]

Yeah, see:

cl-autowrap/autowrap/c2ffi.lisp

Line 77 in 1bdb99e

(with-temporary-file (:pathname tmp-macro-file

Make sure *trace-c2ffi* isn't set, and make sure the uiop temp file function is actually doing what it should... eg call this directly yourself a few times and look at the filenames it gives you.