Closed mahesh-hegde closed 1 year ago
I think as @HosseinYousefi mentioned elsewhere, it's better to test each part of the pipeline separately. Separating getSummary()
part in code is trivial and dart-lang/jnigen#220 already does that to enable some tests. So closing this as not planned.
Motivation:
The source based summarizer is slow, especially on low end machine. This makes jnigen end-to-end tests take much more time than that of ffigen.
We should be able to test the summary generation easily, and also be able to add tests which ensure both parsers generate similar information.
Ideally, we should be able to either cache the summary, or pass the same summary to different tests. dart-lang/native#685
Ideally, adding a new parser should be easier in future. For example, to parse kotlin sources, or to parse incomplete java sources.
Design 1: caching summary
.java
file in source_path or.jar
or.class
file in class_path is newer than the cached summary, or related config is modified.5
summary caches, least recently used one is evicted, (or upon a hash collision).Design 2: Explicitly dumping and passing summary
This is a simpler design.
jnigen:write_summary file --config=...
writes summary to specified filejnigen ..... --summary-file=
reads the summary from specified file instead of parsing.Other tasks