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

Configure to work with macOS NCurses? #7

Open
iandol opened this issue Oct 31, 2022 · 4 comments
Open

Configure to work with macOS NCurses? #7

iandol opened this issue Oct 31, 2022 · 4 comments

Comments

@iandol
Copy link

iandol commented Oct 31, 2022

Hi, ncurses comes with macOS, but to make use of it the naming is slightly different. In homebrew there is a rule that replaces lncursesw with lncurses:

inreplace %w[configure Makefile], "lncursesw", "lncurses"

But it would be better if the configure script could handle this platform detail automatically. Your configure script is a shell script so you could use something like:

PLATFORM=$(uname -s)
if [[ $PLATFORM = 'Darwin' ]]; then
  ...
fi

For the makefile, at least according to stack exchange:

UNAME_S := $(shell uname -s)
ifeq ($(UNAME_S),Darwin)
  LDFLAGS+=-lncurses
else
  LDFLAGS+=-lncursesw
end

I can make a pull request if you want...

@folkertvanheusden
Copy link
Owner

folkertvanheusden commented Oct 31, 2022 via email

@iandol
Copy link
Author

iandol commented Oct 31, 2022

Honestly, I'm not a C programmer and thus ignorant of which make tools are considered better. I'm just an end user who knows enough to be dangerous! 🙃

httping seems to compile well enough with your existing shellscript + makefile, and at least from the view of homebrew, as long as upstream (httping in this case) handles issues like this, it is OK. I'm sure cmake is a more elegant tool, but is there really a need for an extra build dependency?

@folkertvanheusden
Copy link
Owner

folkertvanheusden commented Nov 1, 2022 via email

@iandol
Copy link
Author

iandol commented Nov 1, 2022

OK, I'll leave this issue open for the moment, I think we can get V2.9 back in the public repo without needing this to be completed, and a future release using cmake can make future release more robust when building cross-platform...

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

No branches or pull requests

2 participants