* Switch bash, debugger, less, telnet[d] and top apps to use termcap
functionality provided by ncurses lib instead of GNU libtermcap.so;
* NetBSD version of tput utility replaced with ncurses' one. Fixes#9606;
* terminfo database is provided as mandatory package installed during
building target system;
* Remove libtermcap module. The termcap database source and
corresponding build rules are not removed to provide backward compatibility -
until all optional packages will be rebuild on upcoming system version
using terminfo. Note that gcc2 builds may require to provide termcap a bit
longer in the sake of binary compatibility with R5 era apps.
* Add optional packages Zlib and Zlib-devel.
* Simplify the build feature section for zlib and also extract the
source package.
* Replace all remaining references to the zlib instance in the tree and
remove it.
SharedSolver was archiving too many constraints, partly because of
multiple typos, also because it archived some which were just artifacts
of the layout process. These extra constraints are created when the
layout calls SetRange() on the left/top/right/bottom tabs during layout.
* LinearSpec/ActiveSetSolver had to be adjusted to get access to the
constraints added by the SetRange() calls.
* BALM::TabBase was adjusted to avoid a segfault during unarchiving,
caused by an unitialized member.
* ALMFriendLayoutTest was adjusted to include a more obvious custom
constraint for testing.
Also make ALMGroup totally self-contained, i.e. BALMLayout no longer
does the parsing, and is completely unaware of ALMGroup. A small touch
of refactoring as well.
* allow for independent left, top, right and bottom insets
* allow for independent vertical and horizontal spacing between tabs
* allow for the usage of Haiku's spacing constants such as B_USE_WINDOW_INSETS
The gcc2 cross-compiler built on Mac OS X Lion has a bug in it
where it is erroring with 'cast specifies signature type' when
assigning 0 or NULL to a pointer to a member fuction. NULL in this
instance is correctly converted to 0 since it is illegal to assign
((void*)0) to a pointer to a member function. However, it should
be legal to assign 0 to a pointer to a member function. Thus, there
is a bug. Since I can't fix the gcc2 compiler I am working around
this bug by assigning the pointer to a do nothing function instead.
My host compiler version is
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
The same error occurs using the default gcc-llvm compiler and
a standard gcc 4.61 built from source. This bug does not occur on
Mac OS X 10.6 gcc2 or gcc4, nor does it occur on Mac OS X 10.7 with
the gcc4 cross-compiler.
If and when we decide to finally leave gcc2 behind we can revert this
change.
