congo-cc
Improve handling of templates
There appears to be a current assumption that template folders (src/templates/<lang>) are just one level deep. This is unnecessarily limiting particularly for the C# case, because the dotnet ecosystem sadly has a somewhat brain-dead approach to directories.
It would be more flexible if we could support having paths in template names which we use in output, e.g. 'test/Foo.cs' which would output to a subdirectory test of the output directory. This is currently not possible because even when the output path is correctly resolved, getFileName() is called to get the filename to be written, losing any intervening path elements.
https://github.com/congo-cc/congo-parser-generator/blob/45c003068313c61883c97af1f3cd7131997d9879/src/java/org/congocc/codegen/FilesGenerator.java#L113-L118
if p is foo/Bar.cs, then we correctly resolve to <output dir>/foo/Bar.cs, but then
https://github.com/congo-cc/congo-parser-generator/blob/45c003068313c61883c97af1f3cd7131997d9879/src/java/org/congocc/codegen/FilesGenerator.java#L142-L144
and
https://github.com/congo-cc/congo-parser-generator/blob/45c003068313c61883c97af1f3cd7131997d9879/src/java/org/congocc/codegen/FilesGenerator.java#L188-L191
we lose the foo/ part when computing the template name. It should be foo/Bar.cs but we compute Bar.cs due to using getFileName().
Well, I don't really know what to say about this issue. Just go ahead and deal with it.
In terms of the C# examples generally, couldn't we just roll up the various parsers as libraries (or is assembly the right term?) and then have a little test program that is kind of separate but just uses the relevant library? Surely one can do that, no?
