Hey ccrause,
Thank you for sharing your project.
You're more than welcomed!!
If I'm completely honest, this is pretty much in a state of incompleteness. I say this because the only real trial, was against raylib.h, and that was all through codex. I didn't really double check things.
The tool works with 2 passes. Both using clang. The first one is to untangle the pre-processor mess. But it's not fully clang driven.
The first pass then has to be parsed
manually in order to make sense of it. Also, any function like macro is
not parsed into inline functions in Pascal. That would make it go into quite the dark sides of black magic...
The second pass is the AST itself, and at the moment, basic types( mostly covered in the Pascal ctypes unit ), struct types and functions is the only thing it knows.
I have bashed my head a lot trying to create create Pascal wrappers for esp-idf. Take esp_wifi.h as an example:
1. How should the environment be prepared to handle included header files, and also header files implicitly used.
a) Can a manual list of header files be specified so that fp-h2pas can pass these to clang so that it can resolve the references?
b) Can fp-h2pas parse the header file automatically and try to locate at least the explicit include files?
c) "Standard" types such as uint32_t are defined in <stdint.h>, can clang be convinced to resolve these definitions automatically?
1.a) At the moment, the tool accepts a single header file, and outputs the
translation to STDOUT, or to a file via -o file.pas, so one file at a time.
1.b) Yes, the parsing is automatic, but it will not drill down on any include files.
1.c) If the type can be matched to the Pascal unit ctypes, you're good. Outside of that, I'm not sure. Remember that after it was generated by codex, I haven't had time to look into the generated code.
2. Error messages are currently obscured by the current console text generated, even if an output file was specified.
a) Do not output the header text by default, make it optional for example only emit this if a verbose option is specified for fp-h2pas.
b) Perhaps summarize errors at the end of the output stream, this makes it easy to see.
2.a) I can maybe do that. But these tools are quite crude: Get input from file, spew translation to STDOUT if no flag says otherwise. You can maybe pipe STDERR to another file, just as a quick fix.
2.b) Not a bad idea. I'll put that on my todo list!!
3. Can a custom mapping of C types to Pascal types be specified? E.g. fpc already knows int8 which corresponds to the C type int8_t. I feel queasy when I see type definitions declared with the _t appendix.
No, the tool is still quite toy like. So, no advanced features yet.
4. Currently bitpacked structs such as wifi_ap_record_t is not correctly converted to Pascal. A working solution is to use advanced Pascal records with helpers to pack/unpack bits.
Yeah, like I said, if it's under Pascal's ctypes unit, you're golden. Anything outside that, I need to investigate.
Cheers,
Gus
Recent
