-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix build for linux-arm64 and linux-riscv64 #274
base: master
Are you sure you want to change the base?
Conversation
…#247) (fusesource#258) * Fix wrong output encoding on Windows with JDK >= 19 JDK 19 has changed the system properties used for System.out and System.err encoding, see https://www.oracle.com/java/technologies/javase/19-relnote-issues.html#JDK-8283620 * Fix bad background in logo and add output encoding system properties
- the minimal build requirement is bumped to JDK 21 - FFM is the default provider if available (JDK >= 21 with --enable-preview flag)
@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. Would you mind retargeting this PR to https://github.com/jline/jline3 ? |
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 PR fixes the following issues
make native-all
does not build for linux-riscv64;CCFLAGS
andLINKFLAGS
of linux-arm64 and linux-riscv64 are not used;-mfloat-abi=hard
and-mfpu=vfp
are invalid for arm64.