Well, I didn’t have much huge achievement yesterday – day 4 of our Novell’s Hack Week. But here is a list of things I’ve done to improve the robustness of the converter script.
- Added support to (semi-)correctly parse the preprocessing macros, both ones that take no arguments and ones that do take arguments, as well as ones that include other macros recursively.
- Added support to parse header files, without which many preprocessing macros would be left undefined, thus causing a parse failure.
- Added arithmetic support, again in the preprocessing macros.
- Numerous bug fixes that were uncovered while working on the preprocessing macro support, as well as some re-write of the algorithms to make them work better.
My conclusion? Preprocessing macros are evil! Since macros are expanded before the source file is parsed, it has its own syntax rules that are different from the host language. A simple expansion is rather easy, but once they start taking arguments, recursively using other macros (or the combination of the two), things become a bit tricky. Anyway, the worst is over I hope…
With this improvement, I can now correctly convert 80% of all of the src files we have in our OO.o source tree. Hopefully I can squish the remaining 20% today.
To recap (for those who missed my previous Hack Week posts), I am working on writing a .src to .xml converter script to migrate the existing dialog resource files (which are statically designed) to new xml format that has layout information. The new xml files will be used as a starting point for re-designing all our existing dialogs for the new dialog layout engine in development.
Would it help to use an existing tool (like GCC’s cpp) to preprocess the src files, and then work on the output of that?
Hi Stephan,
I certainly would… I didn’t know you could do that. :-) Although there are certain defined macros we don’t want to expand, such as RID_, SID_, etc, so some manual intervention would still be necessary even if I used GCC to expand preprocessings.