Repository navigation
Output config structure #738
Description
- Added
root_packageoption, which allows simpler hierarchy if all classes are from same package. For example, instead oforg/apache/pdfbox/pdmodel.dartwe can createpdmodel.dart, by telling that root_package isorg.apache.pdfbox.
I presume we add this because it is annoying for people. 😄
Though, Java explicitly doesn't support this.
The question is should we make our bindings look mostly like Java or mostly like Dart? (With ffigen in C, we say that when you write code against generated bindings, you're writing C in Dart syntax. So we're okay with violating dart naming for identifiers etc. With that reasoning, maybe we should stick with the nested folders, because it is more Java-esque.)
I would like to unify everything that influences only output structure in the config:
output:
dart:
path: 'lib/src/third_party/pdfbox/'
output_structure: single_file || package_structure
c:
## Root for generated C bindings.
path: 'src/'Also, maybe we could clean up the C output
output:
dart:
path: 'lib/src/third_party/pdfbox/'
output_structure: single_file || package_structure
c:
path: 'src/third_party/' # both generated C file and makefile?
cmake_path: 'src/' # To make Flutter happy?Originally posted by @dcharkes in dart-archive/jnigen#87 (comment)
Reacted by Mahesh Hegde
Activity
mahesh-hegde commentedon Oct 5, 2022
That's a great question. I am trying to make jnigen-generated packages look like dart packages, which may not really be needed 😃. It seemed pretty easy to implement. Overall it may have required 20 lines max.
Also output config unification sounds good.
dcharkes commentedon Oct 5, 2022
Let's leave out
un_nestfor now then. If we have many users asking for this later, we can always add it later.mahesh-hegde commentedon Oct 7, 2022
@dcharkes do you want this config format change in the current PR or a later PR? Which one is easier for reviewing?
dcharkes commentedon Oct 7, 2022
More, smaller PRs is easier for reviewing.