[haiku-development] Re: What to do with termcap? Scene II.
- From: Siarzhuk Zharski <zharik@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 18 May 2013 13:45:57 +0200
Hi, Ingo,
Ingo Weinhold писал 17.05.2013 16:54:
b) Currently we have ncurses without wide characters support that can
produce problems in hypothetical case of localizing corresponding
tools.
AFAI understand it this has not so much to do with localization as
with support for multi-byte character encodings (like UTF-8). So it is
definitely something we want to enable.
I have talked about stock version of ncurses only. I hope it goes away
sooner than someone dares to localize top, telnet or ftp - so this is
irrelevant IMO. :-)
May be we should activate wide characters support for the stock ncurses
now?
I already did that in the PM branch (I also updated to 5.9). Note
that enabling wchar support actually results in a set of libraries
with a 'w' suffix and a different interface. Since there are programs
that require the non-wchar libraries one has to build both.
The same here - stock version is used only for internal purposes - if we
will not install libncurses.a with Development package anymore we should
not care about names. By the way the name of libncurses.a defined in our
own Jamfile so we do not mimic those "w" suffixes anyway. The optional
packaged version of ncurses will have to follow the standard of course.
The third step was to add terminfo database distribution support for
every type of Haiku builds. It was a bit tricky because ncurses
distribution model requires issuing so known terminfo compiler (tic) to
compile the database directly on the target system using terminfo.src
as
source.
Keeping in mind all cases of cross-compiling I have seen following
variants:
a) Use the ncurses' terminfo compiler tool (tic) provided by build host
system. Note that tic is heavily dependent on libncurses functionality
so full-blown ncurses installation will become pre-requisite for all
host build systems. For Haiku that means creating ncurses optional
package, outsorcing the stock version of ncurses and modifying build
system correspondently. Sooner or later it will be implemented in this
way, but at the moment I had not enough time resources for this variant
:-(
IMO this is the only reasonable option. In the PM branch ncurses
Agree. It is most reasonable one. But not the easiest one.
already is a mandatory (external) package.
To produce the terminfo.src -> terminfo database compilation we must
have the tic executable running on the host system: either a) build as
cross tool or b) taken from the host system ncurses installation. This
step cannot be resolved by just installing the package (excluding
precompiled terminfo database package of course :). In case a) we have
to either reproduce all ncurses' configuration/build steps by yourself
or just run it's makefile as sub-process. I found it unpractical and a
bit unrelated to the Haiku build process. The case b) adds extra
dependency to the host system and I found that unpleasant. That's why I
tried to avoid all those issues by introducing rtic tool. I see the only
potential drawback of the "rtic"-way: the binary format incompatibility
with the future versions of ncurses. But the current terminfo entry
format follows the standard one used for decades in various Unix
systems. Extended capability extensions introduced by ncurses are also
implemented in flexible way so I see no reasons for big changes here.
We haven't removed the
ncurses sources from the Haiku source tree yet and it is still used
for the tools you listed above, but at least the Haiku package doesn't
include the ncurses header or libraries anymore. If you want, feel
free to continue your termcap/ncurses work in the PM branch. It might
save you some work, since the branch is already a bit further in this
respect.
Thank you for the invitation. My list of TODOs and fixes I have planned
for this "fix the Terminal" season is almost empty. I have digged into
stock ncurses just because it is related to that termcap/terminfo stuff
which I tried to bring in order. So I have no more open ideas for this
direction - rtic is perfect ;-) and my message was just kind of report
to community about results: either it accept my proposal, reject it or
take it into account for the future. In afraid of burnout I'm going to
switch to some of my other unfinished projects like USB audio or like
it. So, sorry. ;-)
The drawbacks would be that there's no promise when exactly
the branch will be merged back into the master and it's still gcc 2
only.
It is clear - the package management is the very resource consuming
task. After playing with Haiku port of pkgsrc I understand your discreet
optimistic meaning. :-)
From the other side I prefer small-steps tactic: do the change in single
direction and let the people test any possible side-effects of this
change. That's why I proposed to perform this switch independently of
ncurses outsourcing.
--
Kind Regards,
S.Zharski
Other related posts:
