Decide where to put zlib bindings

[WojciechMazur]

In #3427 and #3389 we created a solution allowing to remove zlib bindings from main sources. The new question now lies where to put the bindings? The nativelib shall be just a Scala Native Runtime Library and should not contain any redundant definitions.
We have a few possibilities here:

• leave bindins in nativelib even though they don't fit here
• move them to javalib - zlib is used only in javalib to implement zips support. Moving them here would make them non-reachable for library authors who would need to reimplement them. The problematic part is that if we would find 2 different signatures of the same symbol the compilation outputs may be undefined. It might happend if 1 library uses incorrect types for binding types.
• create a new project containing bindings to common native libraries, which might be used in Scala Native implementation itself or by 3rd part libraries

[ekrich]

Part of the longed term goal I have been working on was to allow the C code that is used to be put in the corresponding Scala dependencies so they are packaged directly.

This PR #3437 was related to the concept of having the C code to be organized with the project which has the Scala interface. We only have the explicit dependencies between the Scala portion of the project in the build which means the the C code can be used across logical projects such as the example above where someone has the GC code calling libunwind directly in C. I didn't investigate when that got put in but that is causing an explicit dependency between the two.

Even though we can't very well have a system without GC or perhaps libunwind it does not necessarily follow that they all have to be bundled directly together. We also could consider breaking the runtime into user and non-user facing APIs to help avoid people using internal APIs. This would be akin to the sun.misc.Unsafe API. Smaller pieces also make the internal dependencies explicit and maybe makes maintenance easier. At least it might be easier to focus on a smaller subset of the code.

Isn't it also possible for someone to just modify the build plugin to change the dependencies so they could experiment or do research easier?

[LeeTibbert]

To paraphrase Montesquieu, the best is the mortal enemy of the done well enough.

My preferences would be first javalib, then "leave where it is". To my thinking, if javalib is the sole site
of usage that is where the Scala "glue" should be.

Are they currently any known or believed users in the wild of standalone zlib glue code?
How closely does this yak need to be shaved? Perhaps a good shampoo and a few snips on
the flanks is sufficient to the identified need.

[WojciechMazur]

Are they currently any known or believed users in the wild of standalone zlib glue code?

Based on GitHub search probably not, altough better search results might be achived when checking actual source code/tasty of all SN libraries from ScalaDex

[LeeTibbert]

So when the upcoming/desired java.net.zipfs is implemented, the SN tool chain will be the only confirmed user?
There, the use will be, I believe, through javalib.

re: check actual source of all SN libraries

A good thought experiment. Is that precision and expenditure of limited developer time
needed in order to make a reversible decision? Can the decision be made easier to reverse?
I pose the 'not quite rhetorical' questions attempting to be collegial & supportive and walk
through a Pareto 80/20 (99.9/ 0.1?) decision tree.

[JD557]

create a new project containing bindings to common native libraries, which might be used in Scala Native implementation itself or by 3rd part libraries

Just a quick heads up here, I was looking at other things in the code and noticed this line:

scala-native/tools/src/main/scala/scala/scalanative/build/LLVM.scala

Line 192 in fd8d9bd

case Link("z") if config.targetsWindows => "zlib"

In general, I think it would be nice if this mapping was not hardcoded, but I think it's acceptable if zlib is part of the nativelib.
However, if we decide to create a new project for bindings with common libraries, it would be great to have a more general solution to this problem.