Yea, all your points are correct. The library's header files would have to be available, together with the MinGW/system headers. Since it uses libclang it doesn't need a C compiler directly - just the headers.
This is relatively easy on GNU/Linux, or if you have MinGW anyways because you had to compile the C library. However, if you have only downloaded a precompiled library for MinGW, but don't have MinGW itself, then it won't work.
compile-time bindgen for FB
Re: compile-time bindgen for FB
Is the fbc allready using a clang compatible AST? Otherwise it's not sufficient to implement it. The required features are available in fb-frog or h_2_bi (drops a dependency).dkl wrote:Yea, all your points are correct. The library's header files would have to be available, together with the MinGW/system headers. Since it uses libclang it doesn't need a C compiler directly - just the headers.
IMHO that's no problem, since this concept needs a lot of new and special requirements. Ie. the FB code has to be case-sensitive, in order to use the C symbols directly. See also this discussion four years ago:dkl wrote:This is relatively easy on GNU/Linux, or if you have MinGW anyways because you had to compile the C library. However, if you have only downloaded a precompiled library for MinGW, but don't have MinGW itself, then it won't work.
viewtopic.php?p=193727#p193727
What about adding this feature as a loadable module (keeps the fbc lightweight)?
Re: compile-time bindgen for FB
Indeed, I was thinking of a standalone bindgen program; fbc can invoke it and read in the temporary .bi file. The special cases like symbol renaming would have to be specified as options somewhere (maybe in a wrapper .bi file, or an .ini file). All in all it shouldn't affect FB code any differently than a pre-made binding.
I thought about adjusting fbfrog for this, but I'm not sure. On the one hand, libclang provides a complete preprocessor and parser for C and C++ which you can rely on (better than fbfrog's). On the other hand, libclang can't do some things that fbfrog needs (e.g. parsing inside #define bodies, or #pragma pack not being exposed yet), and it turned out to be not super-easy to convert. I learned that parsing libclang's AST is rather ugly, too.
I thought about adjusting fbfrog for this, but I'm not sure. On the one hand, libclang provides a complete preprocessor and parser for C and C++ which you can rely on (better than fbfrog's). On the other hand, libclang can't do some things that fbfrog needs (e.g. parsing inside #define bodies, or #pragma pack not being exposed yet), and it turned out to be not super-easy to convert. I learned that parsing libclang's AST is rather ugly, too.
Re: compile-time bindgen for FB
I'm thinking of a module that the compiler loads at run-time on demand. No temporary .bi file (but .bi wrappers, if need be).dkl wrote:Indeed, I was thinking of a standalone bindgen program; fbc can invoke it and read in the temporary .bi file. The special cases like symbol renaming would have to be specified as options somewhere (maybe in a wrapper .bi file, or an .ini file). All in all it shouldn't affect FB code any differently than a pre-made binding.
Without the temporary .bi file, there's no need to parse inside #define bodies, or #pragma pack. fbc can pass that header code 1:1 to the C output. In case of #define, fbc only needs the symbol name and the number of parameters. A downside is of course, that fbc cannot fetch all error cases. The user may get an error message from the C compiler (but gets up-to-date headers).dkl wrote:I thought about adjusting fbfrog for this, but I'm not sure. On the one hand, libclang provides a complete preprocessor and parser for C and C++ which you can rely on (better than fbfrog's). On the other hand, libclang can't do some things that fbfrog needs (e.g. parsing inside #define bodies, or #pragma pack not being exposed yet), and it turned out to be not super-easy to convert. I learned that parsing libclang's AST is rather ugly, too.