Hi. I’m trying to use ncurses from Ada, and the best way seems to be the ncursesada crate. But of course, I ran into a problem. It doesn’t link. After a fair bit of rummaging around, I found that the problem is that the linker expects the library to be called libadacurses.a, but the build step produces libAdaCurses.a. I added a symbolic link, and then it worked (well, apart from missing TERMINFO).
My question is: who do I report this to? I can’t seem to find where the filename difference originates.
An alternative way to get that information is to directly ask to alr with the show subcommand:
$ alr show ncursesada
ncursesada=6.3.0: Ada binding to the ncurses text user interface library
Origin: commit c6c68b5b2a7ac94d7fa980d2fc3e7d78c50b55e3 from https://github.com/Blady-Com/ncurses.git
Available when: (case OS is Linux => True, Macos => True, Windows => False, others => False)
Properties:
Post_Fetch run: sh configure (from ${CRATE_ROOT}/.)
Post_Fetch run: make libs (from ${CRATE_ROOT}/.)
Author: Thomas E. Dickey
Author: Juergen Pfeifer
Author: Eric S Raymond
Author: Alexander V Lukyanov
Author: Philippe Blain
Author: Sven Verdoolaege
Author: Nicolas Boulenguez
Description: Ada binding to the ncurses text user interface library
License: X11 OR MIT
Maintainer: Pascal Pignard <blady.net@orange.fr>
Maintainers_Logins: Blady-Com
Name: ncursesada
Project_File: Ada95/lib_adacurses.gpr
Tag: ncurses
Tag: binding
Version: 6.3.0
Website: https://github.com/Blady-Com/ncurses
Dependencies (direct):
m4_tool*
diff --git a/Ada95/lib_adacurses.gpr b/Ada95/lib_adacurses.gpr
index f2e69c80..42742f2e 100644
--- a/Ada95/lib_adacurses.gpr
+++ b/Ada95/lib_adacurses.gpr
@@ -11,7 +11,7 @@ library project Lib_AdaCurses is
for Library_ALI_Dir use Library_Type & "-ali";
for Library_Kind use Library_Type;
- for Library_Name use "adacurses";
+ for Library_Name use "AdaCurses";
case Library_Type is
when "dynamic" =>
Does anyone have a simple example using the crate? I’m reluctant to post a PR without testing it, and the provided samples all fail with (a) not using Alire, (b) [on this Mac] Error opening terminal: xterm-256color.
with Terminal_Interface.Curses; use Terminal_Interface.Curses;
procedure Ncurses_Test is
begin
Init_Screen;
End_Screen;
end Ncurses_Test;
Works for me (under WSL). I haven’t quite figured out why this particular version of ncurses doesn’t accept the usual settings, but you can get the application to run by doing this in the shell before starting the binary (or before opening the IDE, if you run the app from an IDE):
Thanks for reporting.
The case error of library name happens when the OS file system is case sensitive.
Unfortunately macOS is not, so, I wasn’t able to detect the error
I’ll post a fix on Alire.
In the meantime, you may use the following workaround in your ncursesada* folder:
% alr exec – ./configure --with-ada-libname=adacurses
% alr exec – make
You can configure your macOS disk format to be case sensitive, but changing a filesystem is not without problems (I’ve had a sample library with hundreds of thousands of files, and two of those were identical modulo capitalization, which caused weird errors; the other way around may cause problems when you’ve stored path names, in a file, database, symbolic link, etc., with a different capitalization). It might be something to consider for a separate development partition, though.
