kaitai_struct_compiler
kaitai_struct_compiler copied to clipboard
Output comment explaining code generation to Construct compiler
Add comment to the top of Construct source files explaining to edit the ksy and recompile. Other targets already have this, so Construct should too.
Sample output with this change:
# This is a generated file! Please edit source .ksy file and use kaitai-struct-compiler to rebuild
from construct import *
from construct.lib import *
example = Struct(
'field1' / LazyBound(lambda: shared__thing),
)
_schema = example
Since construct target is a python target, the raw python target and the construct one should inherit fromthe same class and the comment should be output by it.
Also the comment text should be stored in 1 string shared by all the targets.
It looks like most of the language compilers get access to that header comment from ObjectOrientedLanguage. The ConstructClassCompiler doesn't have the same inheritance chain (or really the same general structure at all), so unless I'm missing something, accessing this value from ObjectOrientedLanguage is going to require a more in-depth change to ConstructClassCompiler than I'm comfortable making with my limited (re: non-existent) Scala experience.
At this point the most I'm comfortable with is pulling that string out to a shared constants file and dropping a TODO tag in there or something. That would at least bring the Construct compiler closer to parity with the others. If we want to refactor inheritance chains, that really should be its own separate PR.
At this point the most I'm comfortable with is pulling that string out to a shared constants file and dropping a TODO tag in there or something. That would at least bring the Construct compiler closer to parity with the others. If we want to refactor inheritance chains, that really should be its own separate PR.
I completely aggree.
Took me a bit to get back to this. I've pulled the header out to a separate constants file.
Some notes:
- Nim does not appear to use a header, so I did not touch the Nim compiler.
- Go uses its own header. It used to inherit the header from
ObjectOrientedLanguage, so since that header now comes from a constant, I just removed theoverridehere. I don't want to change that behavior for anybody using the Go compiler.
I guess it may make sense to reorder the commits. First the ones with refactoring. Then the one with Construct.
I'm not sure what the deal is with these failing tests, but the same tests fail in master