Per Bothner writes:
> You need to analyze CNI (i.e. C++) source code. You need to recognize
> CNI field and method references, which are just C++ field/method
> references. That implies a semantic analysis of the C++ code.
Yep.
> The logical tool is a compiler. The only C++ compiler we have
> available is G++.
ANTLR? Bootstrapping issues aside.
> It does not emit C source. Adding an option to emit C is a major
> project. It is even worse if you want human-readable C.
Granted. I wasn't focused on G++.
> What you can do is convert annotated-CNI to JNI C.
What do you mean by annotated-CNI?
> That loses some of the simplicity of CNI
Is a modification of gcjh a good way to simplify the task for
the parser/converter? I.e. marking Java-turned-C++ classes,
enforcing naming schemes/prefixes etc.?
> However, that is a quite different idea.
Having parts of the toolchain being pure Java (along with the
ability to compile them to native code for bootstrap) is the
foundation for much more portability. I'd prefer e.g. an ANTLR
solution for that reason alone, given that the feasibility
of either approach still seems equally dubious to me :-\.
b.
