Skip to content
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

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

Glavo
Copy link
Contributor

@Glavo Glavo commented Oct 6, 2023

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
Copy link
Member

gnodet commented Oct 10, 2023

@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
Copy link
Contributor Author

Glavo commented Oct 10, 2023

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
Copy link
Member

gnodet commented Oct 10, 2023

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
Copy link
Member

gnodet commented Oct 10, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants