Controlling processed include files
I'm trying to use c2hsc to generate bindings for the chromium embedded framework. The recommended way to use the library is as a binary distribution with associated header files. These include C++ headers, a list of C API headers in the "capi" directory, and a directory of internal headers in "include".
When I run c2hsc with the following command c2hsc --prefix=Bindings.CEF3 --cppopts=-I/home/dan/Code/bindings-cef3 include/capi/cef_app_capi.h, I get this error from the preprocessor.
include/capi/cef_app_capi.h:39:9: warning: #pragma once in main file [enabled by default]
#pragma once
^
In file included from /home/dan/Code/bindings-cef3/include/internal/cef_types.h:46:0,
from /home/dan/Code/bindings-cef3/include/capi/cef_base_capi.h:39,
from include/capi/cef_app_capi.h:41:
/home/dan/Code/bindings-cef3/include/internal/cef_types_linux.h:38:21: fatal error: gtk/gtk.h: No such file or directory
#include <gtk/gtk.h>
^
compilation terminated.
c2hsc: /tmp/cef_app_capi13148.i: removeLink: does not exist (No such file or directory)
Let's ignore for a moment that it can't find gtk. What I'm confused about is why the preprocessor is looking for gtk.h, or internal/cef_types.h. I understand that it is seeing #include directives and trying to process the files, but the gtk types are not necessary for interfacing with the C API, which is platform agnostic.
So my question is, if it's possible and a desirable goal, how do I control c2hsc to only process the C API defined in the capi directory, and ignore the implementation details defined by lower level header files? If this is a dumb idea, why?
At the moment language-c just calls out to cpp, so there's no way to control which files it reads directly. You can define macros on the command-line; perhaps there is one that will disable the use of gtk from that header file?
Yeah, that was the first thing I looked at, but I didn't see anything obvious (to me, at least). At this point I've done enough manually with bindings-dsl that finishing it manually will be faster than bullying cpp into doing what I want. Thanks anyway, though!