Fix #2781: SN 0.4.x: Expose version of Scala Native plugin being used

[LeeTibbert]

Scala Native versions

This PR is submitted for Scala Native 0.4.x with the hope & intent
that it also be merged into Scala Native 0.5.0-SNAPSHOT.

PR

A developer may now easily determine the version of the Scala Native plugin being used
by sbt:

sbt> scalaNativeVersion
[info] 0.4.6-SNAPSHOT

[ekrich]

LGTM.

[LeeTibbert]

I took a closer look at the log file for the failing multiarch builds.
The

Error:  ld.lld: error: relocation R_AARCH64_ABS64 cannot be used against local symbol; recompile with -fPIC
 Error:  >>>  defined in /usr/xcc/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/sysroot/lib/../lib64/libz.a(deflate.o)

Because it is a system file, the suggestion to recompile is not immediately useful.

While my other active PR runs through CI, I can do a quick search of the web to see if this
is a know FreeBSD issue, possibly with a new package or OS version.

I can not access the qemu system to turn "-v" on to show the entire link command,
options and all. Perhaps there is something there which used to work but
is now causing problems.

[LeeTibbert]

Perhaps the linker suggestion to recompile with -fPIC is not unreasonable.
ci-docker/Dockerfile builds the offending zlib

RUN git clone https://github.com/madler/zlib /tmp/zlib \
  && cd /tmp/zlib/ \
  && git checkout v1.2.11 \
  && ./configure \
  && make install prefix=$QEMU_LD_PREFIX \

I have run out of time this session. I suspect that a solution lies in
changing either ./configure or the make to specify the -DCLAGS="-fPIC"
make might allow setting that on the command line in the Dockerfile
(or setting it might clobber existing CFLAG definitions.)

[LeeTibbert]

Eric's PR #2788 is all green in multiarch. configure finds shared library support there and did not find it in
this PR. I do not know what changed or if this PR will pass multiarch if it is re-started (again).
I am giving up on this taking anymore of my life-energy.

Anyway, I believe the failing multiarch has nothing to do with the change of this PR
and that this PR is ready, in the fullness of time, for review and merge.

[WojciechMazur]

Thank you for this PR! Was the change intended to target only Scala Native development builds or the general usage including users of Scala Native in their projects?
For general usage in user builds there is already a nativeVersion exposed in the ScalaNativePlugin. Even though it's not exposed as a setting, its still possible to use it in the sbt builds. Making it a setting means it can be overwritten, leading to some unexpected results

sbt:scala-native> eval nativeVersion
[info] ans: String = 0.4.5-SNAPSHOT

or

sbt:scala-native> eval ScalaNativePlugin.autoImport.nativeVersion
[info] ans: String = 0.4.5-SNAPSHOT

I guess one of the purposes for that setting would be easier switching between SN version, and easier version updated, but in that we would get into another set of problems - we might eg. try to compile SN using 0.4.x (set using introduced setting) artifacts (eg. javalib, nativelib), using 0.5.x toolchain (set in project plugins).

If this change was intended only for the SN project themself, then I don't what kind of improvement it can give us beside allowing to show SN version at this moment.

[LeeTibbert]

Now that you have SN 0.4.7 out and have nothing to do but wait for the laurels to arrive
in the post, let me reply. I have been holding off out of consideration for our efforts and
not wanting to distract you with a low priority discussion.

There probably is no Labor Day long weekend in Europe, but I wish you a long,
restorative break instead.

All in all, this issue is minor and is meant to increase, not impact, tranquility

Out of order replies, in order to address the, IMO, most pertinent concern first.

Making it a setting means it can be overwritten, leading to some unexpected results

This is directly modeled after the existing sbt> javaVersion. The only difference
that I know about and intended is that scalaNativeVersion does not print to the
screen when it is evaluated.

javaVersion is a Setting. Yes, one would thing that a Setting could be set. There
may be a way to set javaVersion. If there is, it is exceedingly hard for people
with little-to-less-than-astonishing sbt foo to do. I spent several hours trying, without success,
to change the variable (without editing project/Settings.scala that would be
cheating and defeat this discussion point ;-)

Even if I did somehow become clever or informed enough and figured out to change
javaVersion, it would not actually change the JVM which sbt is using. Similarly,
if someone did manage to change scalaNativeVersion it would not change
the SN plugin version in use. The worst that would happen is that there is
a discrepency between the report and the plugin actually used.

As we know, sbt allows one to change the Scala version using the
entirely different "++" command. scalaVersion reports the change,
but is not used to cause the change (I have never tried setting the
scalaVersion directly, probably because I have been educated about
the need for "++".

Do you still have a concern here?

Was the change intended to target only Scala Native development builds or
the general usage including users of Scala Native in their projects?

I would say anyone using the Scala Native plugin. That is anyone using
sbt, not something SN compiler tucks into executable files. (Sorry to be concrete):
application developers and, especially, developers of PRs for SN itself.

I have the code of this PR in my local.sbt and I find it essential. I probably
do not switch between SN versions as many times a day as you, but I do
it often enough that I need to be able to readily confirm that I am actually
using the intended SN version.

I am all-right-Jack, and can pass what I have over the back fence. I do
think it would be useful and potentially cut down SN support costs
to make it more generally & officially available.

I understand & support if you decline to accept. I have bigger fish
in your queue and do not want to stress your sufferance on small fry ;-)

For general usage in user builds there is already a nativeVersion exposed in the ScalaNativePlugin.

There is a UI design issue with consistency, which is fixed by this PR. Why, beyond historical developent,
should eval nativeVersion be different than sbt> scalaVersion. Yes, knowing scalaNativeVersion exist
is also arcane lore, but there is a chance for an application developer to infer/guess it, or see it in
(I forget the magic and always have to look it up) sbt> help keys.

[LeeTibbert]

for future readers "sbt> show NativeConfig" also reveals the currently active Scala Native version.