Mined compilation

Go into the "src" subdirectory.
Select a makefile closest to your operating system. (For your 
convenience, you may set a link ln -s makefile.<selected> makefile).

The following makefiles work on Unix:
	makefile.linux	on Linux (link to makefile.gcc)
	makefile.bsd	on BSD-like systems
	makefile.sun	on SunOS and other System V Unix systems
	makefile.hp	on HP-UX (link to makefile.ucb)
	makefile.ucb	supposed to work on UCB (quite similar to .sun)
	makefile.osx	on Mac OS X (similar to .bsd)
	makefile.curses	on Unix, but should not be used (less functionality)
The following makefiles are intended for DOS-based compilation:
	makefile.cygwin	for the cygwin Unix-compliant environment
	makefile.dj	for djgpp
		compiles on plain DOS, same executable runs in Windows 
		DOS box, supporting long file names under Windows 98/2000
	makefile.djc	for djgpp with PDcurses (not needed)
	makefile.emx.curses	for EMX with curses, deprecated
	makefile.emx.nocurses	for EMX without curses, does not work
	makefile.emx.window	non-working attempt for EMX in window mode
These are only include files:
	mkinclud.mak	rules for making mined
	mkinclud.gcc	gcc compiler parameters
	mkinclud.cc	cc compiler parameters
Turbo-C 3.0 uses mined.prj. Turbo-C 2 uses minedtc2.prj - source files 
have to be converted to MSDOS line ends first.
For VMS, compile the source files mentioned in vms-link.com by hand, 
then use that script for linking.


If you don't find a working makefile, try to adapt one, especially 
select a suitable screen handling mode as commented in the makefile.
5 basic modes are available:
* termio (Unix)
* sgtty (Unix, BSD-style)
* curses (Unix and others, but not recommended)
* conio (DOS-based, detected automatically)
* ANSI (selected if none else chosen and conio not detected)
Also consider the other settings, e.g. the sysV variable (see makefile).


As many people seem to prefer it, a special note about curses:
Older Unix curses implementions can be considered quite a piece of junk.
They used to behave quite clumsy at output, much more than direct 
terminal control, and they dared to obstruct the use of 8-bit character 
sets long in the post-ASCII ages.
Even now, in 2004, the curses function 'meta' to enable transparent 
8-bit input fails to work as announced - on Linux ncurses, if the stty 
setting istrip is in effect, additional direct termio manipulation 
is needed to enable 8-bit input, on SunOS curses, I couldn't find out 
how this would work at all.
Even as of 2004, curses does not yet support UTF-8.
The curses option was originally only built into mined for a quick 
port to VMS where it is automatically selected.

The newer ncurses library does not have these problems any more.
Only very recently, with ncursesw 5.4, it works with UTF-8, but 
is still buggy (opening a menu over double-width characters will 
produce display garbage).
And curses still has another major drawback: it is less flexible with 
respect to colour configuration (selecting a foreground colour only, 
with default background, or background colour only, are not 
established with reasonable documentation at the interface; 256 colour 
mode of xterm is not really supported).
In case anybody still wants to compile a curses version, there is a new 
make target to build it while keeping the system-specific adaptations 
of the various makefiles (so not using makefile.curses):
	make minced
This make target uses ncursesw in order to support UTF-8. 
Be aware, however, that the ncursesw library as of ncurses 5.4 has 
a bug that lets it crash if a UTF-8 sequence with more than 3 bytes 
is written.


On some systems, the compiler may fail to compile the large tables 
for character encoding, keyboard mapping, or Han character descriptions.
On SunOS on Intel, cc does not compile handescr.h (out of memory).
On Max OS X, cc does not compile keymaps/_keymaps.h (strings too long);
also here the unknown linker option -d y would have to be tweaked.
Please use gcc to avoid the problem: CC=gcc make or CC=gcc gmake


A special note for HP-UX:
On an older version of HP-UX, the keyboard mapping tables could not 
be compiled because some entries were too long for the preprocessor.
The option -H20000 is passed to cpp (from makefile.hp) to resolve this.
On a newer HP-UX installation, this might compile well without the option.
If you run into this problem, you can also get around it by 
configuring out the Radical/Stroke input method from keymaps.cfg, 
using a "#" character to comment the line out.


A special note on DOS versions:
* The cygwin environment provides an emulation of the Latin-1 8-Bit 
  character set in a DOS box so non-ASCII characters entered in this 
  version are different from those entered in other DOS-based versions 
  (unless cygwin is configured with CYGWIN=codepage:oem).
* With djgpp, a dual-mode version can be compiled that supports long 
  file names if run in a Windows DOS box (Windows 98, 2000, or later).
* The promise of the EMX environment to be able to compile dual-mode 
  applications does not hold - at least not with curses.
  EMX cannot compile the table with CJK character information (handescr.h), 
  reporting virtual memory exhausted, so this feature has been disabled 
  for EMX.
  I have reenabled EMX building again with 2000.10 but as there have 
  always been lots of compilation and make problems I do not plan to 
  support it in the future as the cygwin and djgpp versions work well 
  and there is no advantage of EMX over them.
* If you want to recompile the djgpp version, the makefile produces 
  a stand-alone version, using the pmode/dj DPMI module which is 
  available from the djgpp distribution. See the makefile for the URL.

DOS binary versions precompiled with cygwin and djgpp are available 
from the mined web site http://towo.net/mined/.
The cygwin download archive includes the cygwin libraries needed 
by mined, so it can be used without an installed cygwin environment.

