dstep
dstep copied to clipboard
jacob-carlborg
Multifile libraries and #include
libdvbv5 is a library with many, many C header files. In those C header files, #include is used to ensure name definition happens before use, thereby avoiding compilation errors. Currently DStep seems to ignore #include and thus any generated module will have undefined symbols.
Currently the files have to be manually amended with import statements to get a compilation. The dependency problem has to be solved manually, which is not something that should have to be done.
DStep should be able to detect which imports are required (based on #includes) and add them.
There is also the need to deliver up somewhere the list of files to be given to the compiler.
Unfortunately translating #include to import is not reliable because these two features don't have the exact same behavior. Remember that #include is textual inclusion and that all header files and the C source code will be merged together to one single file by the preprocessor. Therefore we end up with headers that don't include everything they should and sometime include too much. I've seen header files without a single #include and at the same time are using types not declared in the same file. This works because another header file that does declare the type will be included before the "current" file and everything will be merged together into one file.
This is currently the expected behavior. I have one idea to fix/improve on this. It's possible to ask libclang where a symbol is defined, DStep is already doing this to automatically add imports for some of the standard system header files. DStep basically has list of known system header files, if a symbol is defined in one of them, DStep will add a corresponding import.
I'm thinking this could be extended to non-system header files as well. If you pass a list of files to DStep and if a symbol is defined in any of the files passed to DStep, it can add an import for that.
There is also the need to deliver up somewhere the list of files to be given to the compiler.
Not sure I understand this.
Another annoying problem with header files and #include, or how they are used. It's quite common that in the system header files that a symbol is defined according to the docs/standard in a specific header file. But it's actually defined in a another header file and then included in the correct file. This is usually due to these symbols are being defined in platform specific files and included depending on which is the current platform.
Of course, in core.stdc all these symbols are placed in the modules corresponding to the public header files, not the internal files. Which is correct, but it's making it more difficult for DStep.