Open NWPlayer123 opened 2 months ago
Looking into this, is there a good reason to not use in_file as the lookup key? You're only ever going to be including each file once anyways
https://github.com/encounter/dtk-template/blob/main/tools/decompctx.py#L62
diff --git a/decompctx.py b/tools/decompctx.py
index e86d5ef..56d423a 100755
--- a/decompctx.py
+++ b/tools/decompctx.py
@@ -24,7 +24,6 @@ include_dirs = [
]
include_pattern = re.compile(r'^#include\s*[<"](.+?)[>"]$')
-guard_pattern = re.compile(r"^#ifndef\s+(.*)$")
defines = set()
@@ -59,12 +58,10 @@ def import_c_file(in_file: str, deps: List[str]) -> str:
def process_file(in_file: str, lines: List[str], deps: List[str]) -> str:
out_text = ""
for idx, line in enumerate(lines):
- guard_match = guard_pattern.match(line.strip())
if idx == 0:
- if guard_match:
- if guard_match[1] in defines:
- break
- defines.add(guard_match[1])
+ if in_file in defines:
+ break
+ defines.add(in_file)
print("Processing file", in_file)
include_match = include_pattern.match(line.strip())
if include_match and not include_match[1].endswith(".s"):
is there a good reason to not use in_file as the lookup key?
I'd say no. Some libraries might have headers meant for multiple inclusion, such as STLport and its prologue/epilogue headers, but this is a pretty extreme edge case. The standard decompctx doesn't particularly need to accommodate edge cases like this, though handling them out of the box would be nice.
If a project does happen to run into issues and needs something more advanced, there's the pcpp
module which rb3
's decompctx script uses. It took some work to get running in a way that preserved stuff we wanted to keep though, we certainly have some hacks in there lol
See title, I use #pragma once as my header guard and pass in -once to the compiler, but it seems like decompctx only looks for the ifndef define pattern