Integrate with types from 3rd party bindings

[jonas]

The binding generator should be able to both integrate with bindings for the standard library as provided by Scala Native as well as bindings provided by 3rd party libraries.

For example, one package provides bindings for gtk and another package bindings for a new gtk component. The component package should ideally just declare a dependency on the gtk binding and not have to include bindings for all of gtk.

One idea would be to have the binding generator create a file with types and information similar to the stdHeader.config file which can be packaged together with a binding and then loaded from the JAR.

[jonas]

LLVM modulemaps look interesting: https://clang.llvm.org/docs/Modules.html#module-map-language

[jonas]

The current std-header configuration has one limitation because it uses basename whereby it doesn't allow multiple libraries to have a file with the same name. This limitation should only be an issue if we map 1:1 files to extern objects.

If we instead can trace the entry point of the library this should not be an issue. Libraries may have multiple entrypoints (header files) but then they are usually grouped in a nested directory. It looks like rust-bindgen gets around solves this by requiring that users provide a wrapper header file which includes all header files of the library. This automatically allows to blacklist all other headers.

We still need to keep track of which header file declares which type so that we can reference types correctly. For example, if bzip2 includes stdio.h to use FILE in a method then the generated code should use stdio.FILE in the method signature. For this to work we should use a file similar to std-header to resolve the fully qualified name of the current header file being parsed and add this information as an annotation in the generated types and declarations.

Filtering by this qualified name will make it quite simple to prune methods from external headers. Similarly it will make it possible to report issues with non-existing bindings.

[kornilova203]

Sorry, I do not fully understand what do you mean by fully qualified name of a header file? Library name + path to the file?

[jonas]

As an example the fully qualified name of bzip2 could be org.scalanative.bindings.bzip2.

[kornilova203]

Okay, but we can get this name without a file similar to std-header by simply concatenating package name and lib name, am I right?

[kornilova203]

So, will we generate one scala object from multiple headers of a library? Then we should mark each generated binding with information on where it came from. Will it look like this?:

@extern
object mylib {
  @location("header1.h")
  type union_myUnion = native.CArray[Byte, native.Nat._8]

  @location("header2.h")
  def setIntValue(v: native.Ptr[union_myUnion]): Unit = native.extern
}

[kornilova203]

But I suppose it is not necessary if std-headers contain this info:

mylib {
  object org.scalanative.bindings.mylib
  headers {
    header1.h
    header2.h
  }
}

[kornilova203]

So if parsed library includes header1.h then we can check which library contains this header and include corresponding scala object. But what if two libraries contain header file with the same name?

mylib1 {
  object org.scalanative.bindings.mylib1
  headers {
    header1.h
  }
}
mylib2 {
  object org.scalanative.bindings.mylib2
  headers {
    header1.h
  }
}

[kornilova203]

@jonas, I wrote my thought about this issue here, what do you think about it?

I suggested there new format of config file, but I think that it is too complicated and we should use existing format.

[jonas]

I suggest we move this issue to the 0.3 release and instead tackle #13 instead.