Right now, CodeWiki relies on standalone tree-sitter AST parsing to build the dependency graph. While this works great for high-level and managed languages, systems languages like C, C++, Zig, or Objective-C really depend on build-system context (include paths, macro expansions, compiler flags) to be parsed correctly.
According to the README benchmark results, CodeWiki's performance on Systems (C/C++) repositories sits around 53.24%. A major reason language analyzers struggle with raw C/C++ source files outside of a build environment is missing the preprocessor context. For example, if a macro toggles an #ifdef, the AST parser can easily guess wrong or miss half the call graph.
If we add support for reading a standard compile_commands.json compilation database, we could improve this. It’s highly accessible since CMake, Zig, and Rust can emit them natively, and non-CMake or Obj-C builds can generate them using the bear tool.
How could it help the pipeline?
Jumpstart/Skip Discovery
Instead of walking directories and guessing boundaries, the analyzer can use the compilation database to instantly map out exact translation units and headers.
Preprocessor Accuracy
We can extract include paths (-I) and macro definitions (-D) from the individual compile commands and feed them into the tree-sitter parsers (src/be/dependency_analyzer/analyzers/c.py and cpp.py), so they parse the actual code paths that are compiled.
Possible Workflow
-
Look for compile_commands.json automatically in the root, or add a flag like codewiki generate --compile-commands path/to/json
-
Inject the parsed file list and flags directly into DependencyGraphBuilder before it delegates to individual language analyzers.
Right now, CodeWiki relies on standalone tree-sitter AST parsing to build the dependency graph. While this works great for high-level and managed languages, systems languages like C, C++, Zig, or Objective-C really depend on build-system context (include paths, macro expansions, compiler flags) to be parsed correctly.
According to the README benchmark results, CodeWiki's performance on Systems (C/C++) repositories sits around 53.24%. A major reason language analyzers struggle with raw C/C++ source files outside of a build environment is missing the preprocessor context. For example, if a macro toggles an
#ifdef, the AST parser can easily guess wrong or miss half the call graph.If we add support for reading a standard
compile_commands.jsoncompilation database, we could improve this. It’s highly accessible since CMake, Zig, and Rust can emit them natively, and non-CMake or Obj-C builds can generate them using the bear tool.How could it help the pipeline?
Jumpstart/Skip Discovery
Instead of walking directories and guessing boundaries, the analyzer can use the compilation database to instantly map out exact translation units and headers.
Preprocessor Accuracy
We can extract include paths (
-I) and macro definitions (-D) from the individual compile commands and feed them into the tree-sitter parsers (src/be/dependency_analyzer/analyzers/c.pyandcpp.py), so they parse the actual code paths that are compiled.Possible Workflow
Look for
compile_commands.jsonautomatically in the root, or add a flag likecodewiki generate --compile-commands path/to/jsonInject the parsed file list and flags directly into
DependencyGraphBuilderbefore it delegates to individual language analyzers.