Fix build for linux-arm64 and linux-riscv64

[Glavo]

This PR fixes the following issues

• make native-all does not build for linux-riscv64;
• CCFLAGS and LINKFLAGS of linux-arm64 and linux-riscv64 are not used;
• Compiler flags -mfloat-abi=hard and -mfpu=vfp are invalid for arm64.

[gnodet]

@Glavo as I mentioned last week, I'm planning to rebase JANSI on top of JLine. Jansi will provide the same easy to use API for simple applications, and JLine will provide the underneath access to the console. The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.
The new JNI provider for jline is available at jline/jline3#870 and the PR for jansi will look like #276.

Would you mind retargeting this PR to https://github.com/jline/jline3 ?

[Glavo]

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this.

jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle.

I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

[gnodet]

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this.

jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle.

I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

The point, which I agree with, is to have a standalone and small library for Jansi. The jansi providers are definitely missing some important pieces to be used by JLine. However, we could refactor the JLine providers a bit to make them a better fit for Jansi, without having to duplicate code or bring too much unused stuff in Jansi. I think the way to go is to merge Jansi into JLine, we could then easily refactor the internal parts without impacting the jansi or jline API to suit both needs.

[gnodet]

The switch is imho mandatory in order to not duplicate the work / maintenance on both projects.

Sorry, I don't agree with this.
jline is a powerful library, but many programs don't need these features, so they just use jansi. Many of them are cornerstones of the Java ecosystem, such as Maven and Gradle.
I can understand the idea of reducing duplicate code, but I wish jansi as a standalone library could include these features. Can we make jline deprecate the jna backend and force dependency on jansi? This way we can implement them in jansi without maintaining duplicate code. I believe that after these PRs are completed, jansi will be enough to take on this responsibility.

The point, which I agree with, is to have a standalone and small library for Jansi. The jansi providers are definitely missing some important pieces to be used by JLine. However, we could refactor the JLine providers a bit to make them a better fit for Jansi, without having to duplicate code or bring too much unused stuff in Jansi. I think the way to go is to merge Jansi into JLine, we could then easily refactor the internal parts without impacting the jansi or jline API to suit both needs.

Have a look at jline/jline3#871
This can definitely be refactored, but it provides a standalone jansi jar and removes all code duplication. We just need to move the line a bit lower if we want to avoid bringing too much in jansi. But it provide a single point for console providers implementation, selection, auto-detection.