                        UDO Developer's Guide

                              Version 5
                              27.10.2001

                                 von

                            Dirk Hagedorn
                              Asmecke 1
                            59846 Sundern
                             Deutschland
                  email E-Mail: udo@dirk-hagedorn.de



Inhaltsverzeichnis
==================

 1  Einfuehrung

 2  Was muss angepasst werden?

 3  Makros

 4  Headerfiles
    4.1  import.h & export.h
    4.2  portab.h
    4.3  version.h
    4.4  commands.h
    4.5  udo_type.h
    4.6  constant.h

 5  C-Files
    5.1  abo.c
    5.2  cfg.c
    5.3  chr.c
    5.4  cli.c
    5.5  env.c
    5.6  file.c
    5.7  img.c
    5.8  msg.c
    5.9  par.c
    5.10  str.c
    5.11  sty.c
    5.12  tab.c
    5.13  toc.c
    5.14  tp.c
    5.15  udo.c

 6  UDOs grobe Funktionsweise

 7  Eigene Benutzerschnittstellen
    7.1  Flags
    7.2  Callbacks

 8  Distribution vorbereiten
    8.1  Makefiles
    8.2  Doku und Manualpage umwandeln
    8.3  FILE_ID.DIZ anpassen
    8.4  Archiv erstellen und packen



1  Einfuehrung
**************

Diese Informationen  wurden  erstellt,  um  die  Portierung von UDO zu
erleichtern und um einen kleinen Einblick in  die  Funktionsweise  von
UDO zu geben, welche der Fehlersuche dienlich sein kann.

Urspruenglich war  der  Sourcecode  nur dazu ausgelegt, das UDO-Format
ins ST-Guide-, ASCII- und LaTeX-Format umzuwandeln. Der Sourcecode ist
nun  in  mehr  als  eineinhalb  Jahr  stark  angewachsen  und ziemlich
undurchsichtig geworden. Sehr oft habe ich ohne  grosse  Ueberlegungen
irgendwo  Dinge  hineingebastelt, obwohl sie eigentlich dort nichts zu
suchen haben. Na ja, es laeuft halt.

An vielen  Stellen  koennten  eigentlich   Optimierungen   vorgenommen
werden,   allerdings   ist   dies   eine   zeitaufwendige   Sache,  da
Optimierungen fuer ein Format sich negativ auf  die  Uebersetzungszeit
bei  andere Formaten auswirken koennten. Und um dies zu testen, fehlte
mir letztens einfach die Zeit.

Was auffallen wird, das sind die kurzen Namen der  C-Files.  Dies  hat
folgenden   Grund:   Unter   MS-DOS  kann  der  GCC  dem  Linker  eine
Kommandozeile von maximal 254 Zeichen uebergeben. Haetten die  C-Files
laengere Namen, koennte kein Binary mehr gelinked werden.

Ich moechte  nun versuchen, ein paar Dinge zu beschreiben, die man bei
einer Portierung unbedingt beachten sollte. Dies wird mir nicht  immer
auf Anhieb gelingen, daher betrachtet diesen Text nur als Versuch. Ich
werde versuchen, diesem Text in Zukunft auf dem laufenden zu halten.



2  Was muss angepasst werden?
*****************************

Hier eine  kleine  Aufstellung  der  Routinen  und   Konstanten,   die
unbedingt angepasst werden muessen. Findet Ihr bereits einen fuer Euch
zustaendigen #ifdef, so habe ich Euch bereits die Arbeit abgenommen.

 portab.h     WORD und UWORD definieren

 constant.h   Deutsche Umlaute definieren.

 version.h    Hier muessen Strings fuer die Infoseite gesetzt  werden.
              Darueber    hinaus    werden    weitere    system-   und
              compilerabhaengige Makros gesetzt.

 udo.c        in udo() sollte ein spezielles Zeichen  fuer  die  erste
              Ebene     der    itemize-Umgebung    angegeben    werden
              (itemchar[1]).

 chr_*.h      Hier sind Tabellen fuer die Umsetzung des  Zeichensatzes
              definiert.

 chr.c        Hier   muss   die   passende   chr_*.h sowie   ???2iso.h
              eingebunden werden.



3  Makros
*********

Ich beginne mal mit den wichtigsten  Dingen,  die  unbedingt  beachtet
werden sollten. Fuer #ifdef's sind folgende Makros vorgesehen:

 Amiga:      __AMIGA__

 Atari:      __TOS__

 BeOS:       __BEOS__

 EMX:        __MSDOS__

 Linux:      __LINUX__

 Linux 68k:  __LINUX68K__

 HP-UX:      __HPUX_ISO__ bzw.  __HPUX_ROMAN__,  je  nachdem,  welchen
             Zeichensatz das System verwendet  (ISO-Latin-1  oder  HP-
             Roman-8).

 Macintosh:  __MACOS__

 NeXTStep:   __NEXTSTEP__

 Sinix:      __SINIX__

 SunOS:      __SUNOS__

Bis auf  __TOS__ (von  Pure C vordefiniert) sollten alle Bezeichner im
Makefile gesetzt werden!



4  Headerfiles
**************


4.1  import.h & export.h
========================

import.h beinhaltet folgendes:

     #ifdef GLOBAL
     #undef GLOBAL
     #endif
     
     #define GLOBAL extern

export.h beinhaltet folgendes:

     #ifdef GLOBAL
     #undef GLOBAL
     #endif
     
     #define GLOBAL

Module stellen globale Funktionen und Variablen  in  ihrem  Headerfile
zur  Verfuegung.  Lokale  Funktionen  und  Variablen  werden im C-File
deklariert.

Beispiel:

     #include "import.h"
     #include "that.h"
     #include "export.h"
     #include "this.h"

Modul `this.c' greift auf Funktionen  und/oder  Variablen  des  Moduls
`that.c'  zurueck. Nachdem `import.h' eingelesen wurde, ist GLOBAL als
extern definiert, was dazu fuehrt, dass die Funktionen  und  Variablen
aus `that.h' fuer `this.c' ebenfalls als extern deklariert sind.

Nach `export.h'  wird  GLOBAL umdefiniert  und  beinhaltet nichts. Die
eigenen Funktionen und Variablen aus  `this.h'  werden  fuer  `this.c'
also nicht als extern deklariert.

Diese Vorgehensweise  erlaubt es, auf die unuebersichtlichen und zudem
fehleranfaelligen expliziten extern-Deklarationen zu verzichten.


4.2  portab.h
=============

In portab.h werden derzeit  nur  grundlegende  Dinge  festgelegt.  Zum
einen  die  boolschen Konstanten, EOS (end of string), USE_ISO_CHARSET
sowie WORD und UWORD.

USE_ISO_CHARSET sollte auf 1 gesetzt werde, falls  das  Betriebssystem
den ISO-Latin-1-Zeichensatz benutzt, andernfalls auf 0.

WORD und   UWORD werde   nur   in  img.c benutzt  um  die  Header  der
Grafikformate auszulesen.


4.3  version.h
==============

In diesem  File  werden  ein  paar  Konstanten  fuer   Versionsnummern
gesetzt.   Aber   was   viel   wichtiger   ist:   Auch   hier   werden
systemabhaengige Makros definiert:

 OSUDO:         Ein   String,   der   fuer   den   "Werbetext"    fuer
                `!use_about_udo' eingesetzt wird.

 USE_SLASH:     Soll  als  Pfadtrenner ein `/' verwendet werden? Falls
                ja, als 1 defnieren. Fuer  Unix  ist  dies  immer  der
                Fall.

 USE_LNAME:     Werden  lange Dateinamen standardmaessig unterstuetzt?
                Falls ja, dann mit 1 definieren. UDO  legt  dann  z.B.
                Dateien  mit  der  Endung .html statt .htm an. (Obwohl
                weder DOS noch GEMDOS etwas dagegen  haben,  wenn  man
                versucht,  eine  Datei mit einer ueberlangen Endung zu
                oeffnen, sollte man hier eine  0  setzen.  Grund:  UDO
                benutzt   die   Endungen  auch  fuer  die  Referenzen.
                Erstellt man nun zuhause ein  HTML-File,  kopiert  den
                ganzen Krempel auf den Uniserver, so haetten die Files
                die Endung .htm, die Referenzen wuerden aber auf .html
                lauten  und  schon  wuerden die Files unter Unix nicht
                mehr gefunden.)

 HAVE_STRUPR:   Falls der  benutze  Compiler  kein  strupr() anbietet,
                dann  sollte  hier  eine  0  eingetragen  werden.  UDO
                benutzt dann seine eigene Funktion.

 HAVE_STRLWR:   Falls der  benutze  Compiler  kein  strlwr() anbietet,
                dann  sollte  hier  eine  0  eingetragen  werden.  UDO
                benutzt dann seine eigene Funktion.

 HAVE_STRICMP:  Falls der benutze  Compiler  kein  stricmp() anbietet,
                dann  sollte  hier  eine  0  eingetragen  werden.  UDO
                benutzt dann strcmp().

 HAVE_STRCASECMP: Falls der  benutze  Compiler  kein  stricmp() jedoch
                strcasecmp() anbietet,   dann   sollte   hier  eine  1
                eingetragen werden.

Um die Makros, die sonst noch gesetzt werden, solltet Ihr  Euch  nicht
kuemmern. Auch solltet Ihr hier keine Aenderungen vornehmen, ohne mich
darueber zu informieren!


4.4  commands.h
===============

Hier werden einige Befehle als Makros hinterlegt. Ich  gebe  zu,  dass
man  besser  ein eigenes Modul benutzen sollte, in dem die Befehle als
const char benutzt werden, damit der Praeprozessor entlastet und  UDOs
Binary etwas kleiner wird.


4.5  udo_type.h
===============

Hier werden ein paar Typen deklariert, die moduluebergreifen verwendet
werden. Das Headerfile ist gut kommentiert  und  sollte  weitestgehend
selbsterklaerend sein.


4.6  constant.h
===============

Hier werden wichtige Konstanten fuer den internen Gebrauch gesetzt. Um
die meisten braucht Ihr Euch nicht zu kuemmern.

Wichtig: Hier sind fuer jedes System die  Lage  einiger  Sonderzeichen
anzugeben:

 BETA_C:   Griechisches Beta als unsigned char
 BETA_S:   Griechisches Beta als unsigned char[2]
 ALPHA_S:  Griechisches Alpha als unsigned char[2]



5  C-Files
**********


5.1  abo.c
==========

Dieses Modul  erzeugt  eine  kleine Werbeseite fuer UDO, falls in UDO-
Quelltexten der Schalter `!ude_about_udo' verwendet wird.


5.2  cfg.c
==========

Die Routine liest die Datei namens  udo.ini aus  $HOME,  $UDOPATH oder
dem   aktuellen   Verzeichnis.   Die   Kommandozeilen-Version  benutzt
lediglich die Registrierungsdaten. Die Atari-GEM-Version benutzt  auch
die anderen Eintraege und sichert die Einstellungen auch wieder.

Wer eine  grafische Benutzeroberflaeche schreiben moechte, aus der man
formatzugehoerige Programme aufrufen kann, der sollte sich einmal  die
Struktur  APPCFG,  die  in cfg.h definiert ist, ansehen. Dort kann man
die Pfade der Programme und die passenden Optionen ablegen.

In der Struktur CONFIG werden  auch  einige  weitere  Flags  abgelegt.
Fragt mich bitte, falls der Zweck dieser Flags nicht kommentiert ist.


5.3  chr.c
==========

Hier sind  alle  Routinen untergebracht, die sich um die Umsetzung der
Sonderzeichen und um spezielle Platzhalter kuemmern.

Zu Beginn muessen systemabhaengig die  Uebersetzungstabellen,  die  in
chr_*.h deklariert werden, eingebunden werden.

Dieses File  ist und bleibt eine grosse Baustelle. Gerade neulich habe
ich erst den "universellen Zeichensatz" angeboten und die  zugehoerige
Routine  eingebaut, die noch erschrecken langsam funktioniert und bald
von mir auf den neuesten Stand gebracht wird.


5.4  cli.c
==========

Dies ist  die   Benutzerschnittstelle   der   Kommandozeilenversionen.
Moechte man eine eigene Schnittstelle oder Oberflaeche schreiben, muss
dieses Files quasi ersetzt werden.


5.5  env.c
==========

Dieses Modul verwaltet alle Umgebungen und sorgt durch Berechnung  von
Einrueckungen  dafuer,  dass  Umgebungen  spaeter  richtig  formatiert
ausgegeben werden.

In env.c werden  auch  die  Zeichen  initialisiert,   die   fuer   die
Markierung  der  Items der itemize- und enumerate-Umgebungen verwendet
werden. Diese Zeichen sind teils zeichensatzabhaenig!


5.6  file.c
===========

Die Funktion fsplit() sorgt fuer die Aufsplittung einer Pfadangabe  in
Laufwerk  (z.B. D:, Pfad (z.B. \BIN), Dateiname (z.B. foo) und -endung
(z.B. .bar).

Der Routine ist es egal, ob Pfade durch  einen  Slash  oder  Backslash
voneinander  getrennt  sind. Die Routine wurde noch nicht ueberprueft,
ob sie auch mit Leerzeichen im uebergebenen String zurechtkommt.

Fuer Filesysteme wie die des Mac oder der BeBox stehen hier  ein  paar
weitere Funktionen.


5.7  img.c
==========

Diese Routine   kuemmert   sich   um   Aufgaben,   die   mit  Grafiken
zusammenhaengen. Generell werden nur die Grafikheader  ausgelesen  und
in  einer  Struktur  udo.c: c_image() die Informationen zur Verfuegung
gestellt. Danach werden dann passende Befehle ausgegeben, so dass  das
Zielformat die Grafiken anzeigt.

Wichtig: Fuer  RTF  werden  noch keine Bilder ausgegeben. Falls jemand
weiss, wie man die Bilddaten im RTF  verschluesseln  muss,  bitte  ich
darum, mir diese Infos zukommen zu lassen.


5.8  msg.c
==========

Dieses Modul  kuemmert  sich  um  die  Ausgabe von Fehlermeldungen ins
Logfile bzw. auf die Standardausgabe.


5.9  par.c
==========

Dieses Modul kuemmert sich um die Bearbeitung von  Platzhaltern,  also
Befehlen, bei denen Parameter benutzt werden.

Auch werden  hier  die  Trennvorschlaege (`!hyphen'), Makros (`!macro'
und Definitionen (`!define') verwaltet.


5.10  str.c
===========

Hier werden  Funktionen  zur   Stringbehandlung   bereitgestellt.   Da
intensiv  von  Funktionen wie replace_all() gemacht wird, bin ich sehr
angetan, falls mir jemand schnellere aber  genauso  portable  Routinen
nennen kann.


5.11  sty.c
===========

Dieses Modul kuemmert sich um die Ersetzung und Ueberpruefung der ver-
schiedenen Texteffekte.


5.12  tab.c
===========

tab.c beinhaltet alle Routinen, die fuer den  Tabellensatz  zustaendig
sind.


5.13  toc.c
===========

Dieses etwas  grossgeratene  Modul hat einen etwas verwirrenden Namen.
Denn   es   kuemmert   sich   nicht   nur   um   die   Ausgabe   eines
Inhaltsverzeichnis  (`table  of  contents'),  sondern  beinhaltet alle
Routinen,  die  irgendwie  mit  Gliederungsbefehlen  (`!node'   etc.),
Sprungmarken  (`!label'), Zweitnamen (`!alias') oder der automatischen
Referenzierung zu tun haben.

Dieses Modul wurde zwischen Release 5 Patchlevel 5  und  Patchlevel  6
fast komplett neu programmiert.


5.14  tp.c
==========

Hier werden  lediglich  die  Titelseiten  fuer  die jeweiligen Formate
erzeugt.


5.15  udo.c
===========

udo.c ist  praktisch  das  Hauptmodul,   das   alle   anderen   Module
kontrolliert.  In  diesem  Modul  werden Zeilen eingelesen, abgefragt,
gepuffert und formatiert ausgegeben. Zwischendurch wird  andauernd  in
die obigen Module verzweigt.



6  UDOs grobe Funktionsweise
****************************

Hier werde  ich  versuche,  die  Funktionsweise von UDO in Grundzuegen
darzustellen. Ob mir das gelungen ist, muesst  Ihr  entscheiden,  aber
sicherlich ist diese kurze Auflistung besser als nichts.

Dreh- und Angelpunkt sind eigentlich genau sieben Routinen:

  1. init_vars()
     Hier    werden    interne   Variablen   auf   ihre   Defaultwerte
     zurueckgesetzt und die Sprachstrings auf Deutsch voreingestellt.

  2. init_modules()
     Alle Module werden initialisiert.

  3. udo()
     Das  Herzstueck,  was  alles   weitere   veranlasst,   also   das
     Ueberpruefen,  ob  die  Quelldatei vorhanden ist, das Anlegen von
     Logfiles, der Aufruf von pass1() und pass2() sowie das Schliessen
     aller geoeffneten Dateien am Ende der Uebersetzung.

  4. pass1()
     Im  ersten  Durchlauf werden alle Kapitel, Labels, Aliase, Makros
     und Definitionen ermittelt, die fuer den  zweiten  Durchgang  von
     eminenter   Wichtigkeit   sind,  sei  es  fuer  die  Ausgabe  der
     Inhaltsverzeichnisse oder die automatische Referenzierung.

  5. pass2()
     Im  zweiten  Durchlauf  erfolgt  die  eigentliche  Umsetzung  des
     Textes.   Die   vielen  Anfragen  sind  bedingt  durch  die  hier
     beruecksichtigten verbatim-, raw- und table-Umgebungen sowie  die
     speziellen Umgebungen mittels !ifdest.

  6. tokenize()
     Eine  Zeile  wird  in  Tokens  zerlegt. Falls das erste Token ein
     Kommando enthaelt, wird die  entsprechende  Funktion  aufgerufen.
     Welche,   das  wird  vorher  in  einer  Tabelle  festgelegt.  Die
     aufgerufenen Routinen haben alle den Namen `c_' (sie lauteten mal
     alle  `convert_',  aber  aus  Faulheit  habe  ich  da eine kleine
     Kuerzung vorgenommen). Ist kein Kommando am Anfang des  Absatzes,
     werden   die   Woerter   der   Zeile  in  einen  internen  Puffer
     aufgenommen, der momentan statisch verwaltet  wird  und  auf  800
     Worte ausgelegt ist.

  7. token_output()
     Hier  wird  ein  kompletter  Absatz  ausgegeben.  Dies  ist  eine
     verdammt  kniffelige  Angelegenheit.  Versucht  bitte  nicht   zu
     verstehen, was in dieser Routine alles abgefragt wird.

  8. exit_vars
     Hier werden alle benoetigten Variablen wieder zuruecksetzt sprich
     der waehrend der Ueberstzung alloziierte Speicher freigegeben.

Dies sieht im ersten Moment ziemlich  einfach  aus.  Die  ganze  Sache
waere  auch  recht  einfach,  wenn  man nicht zwischendurch noch genau
beruecksichtigen  muesste,  wann  und  vor  allen  Dingen  in  welcher
Reihenfolge

   . Sonderzeichen,

   . Schriftarten,

   . Trennungsregeln,

   . Referenzen,

   . Makros und Definitionen sowie

   . spezielle Platzhalter

angepasst werden  muessen.  Eine  Aenderung  der Aufrufreihenfolge der
Funktionen  c_macros,  auto_quote_chars,   auto_references,   c_divis,
c_tilde, c_vars etc. hat mir schon manche schlaflose Nacht bereitet.



7  Eigene Benutzerschnittstellen
********************************

UDO ist nicht zwingend als Kommandozeilenversion ausgelegt. Dies zeigt
auch, dass es eine GEM-Version von UDO gibt.

Um verschiedene Benutzerschnittstellen zu  ermoeglichen,  laesst  sich
UDO  ueber das Setzen einiger Flags fernsteuern. Desweiteren muss eine
Routine bereitgestellt werden, die Informationen ausgeben kann.

Welche Routinen genau zur Verfuegung gestellt werden  muessen,  findet
man in gui.h

Wie dies  bei  der Kommandozeilenversion realisiert ist, kann man sich
ausfuehrlich in cli.c anschauen.


7.1  Flags
==========

Die Hauptfunktion udo() kann man durch  folgende  Flags  beeinflussen.
Man  erhaelt  Zugriff  auf diese Flags, wenn man udo.h folgendermassen
einbindet:

     #include "import.h"
     #include "udo.h"
     #include "export.h"
     #include "gui.h"

 desttype: Dieser Integer-Wert enthaelt einen Wert, anhand dessen hun-
     dertfach  entschieden  wird,  in welches Format der gelesene Text
     umgewandelt werden soll. Die Konstanten, mit denen diese Variable
     belegt  werden,  sind  in  constant.h definiert und lauten TOASC,
     TOTEX etc.

 no_logfile: TRUE, falls UDO kein Logfile anzeigen soll.

 no_hypfile: TRUE, falls UDO keine Datei mit Trennvorschlaegen bei den
     ASCII-Formaten anlegen soll.

 verbose: TRUE,  wenn  UDO  ausfuehrliche Statusmeldungen waehrend der
     Konvertierung  ausgeben  soll.  Dazu  wird  spaeter  die  Routine
     infout() aufgerufen,  die  von  der  jeweiligen  Oberflaeche  zur
     Verfuegung gestellt werden muss (siehe cli.c).

 be_quiet: TRUE, wenn UDO ueberhaupt  keine  Statusmeldungen  ausgeben
     soll.

 no_check: TRUE,    falls   keine   Ueberpruefung   der   Schriftarten
     vorgenommen  werden   soll.   Habe   ich   irgendwann   mal   aus
     Geschwindigkeitsgruenden eingebaut.

 testmode: TRUE,  wenn  UDO  keine  Zieldatei,  sondern nur Logile und
     Hyphenfile erzeugen soll.

 use_treefile: TRUE, wenn UDO einen "Include-Baum" ausgeben soll.

Schliesslich uebergibt man udo() den Namen  der  Quelldatei  und  dann
sollte es losgehen.


7.2  Callbacks
==============

Will man  eine  eigene Benutzerschnittstelle schreiben, muessen die in
gui.h deklarierten Funktionen angeboten werden. Diese werden vom Modul
udo.c aufgerufen.

   . show_status_* ( ... )
     Es    sollen   Statusinformationen   ausgegeben   werden,   falls
     be_quiet==FALSE ist. UDO gibt Zeichenketten aus, in denen man den
     aktuellen Stand der Konvertierung anlesen kann.

   . void warning_err_logfile ( void )
     Es  wird  eine  Fehlermeldung  ausgegeben, dass das Logfile nicht
     angelegt werden konnte.

     Hier kann man eine Dialogbox  oeffnen  oder  aber  die  in  msg.c
     angebotene Funktion error_open_logfile() verwenden.

     Der Name des Logfiles befindet sich in logfull.

   . void warning_err_treefile ( void )
     Es  wird  eine  Fehlermeldung ausgegeben, dass das Treefile nicht
     angelegt werden konnte.  Ins  Treefile  wird  ein  "include"-Baum
     ausgegeben.

     Hier kann  man  eine  Dialogbox  oeffnen  oder  aber die in msg.c
     angebotene Funktion error_open_treefile() verwenden.

     Der Name des Treefiles befindet sich in treefull.

   . void warning_err_hypfile ( void )
     Es wird eine Fehlermeldung ausgegeben, dass das Hyphenfile  nicht
     angelegt   werden   konnte.   In   diese   Datei   gelangen   die
     Trennvorschlaege fuer die ASCII-Formate.

     Hier kann man eine Dialogbox  oeffnen  oder  aber  die  in  msg.c
     angebotene Funktion error_open_hypfile() verwenden.

     Der Name des Hyphenfiles befindet sich in hypfull.

   . void warning_err_destination ( void )
     Es  wird  eine Fehlermeldung ausgegeben, dass die Zieldatei nicht
     angelegt werden konnte.

   . void multitasking_interrupt ( void )
     Diese Routine wird aufgerufen, um bei  kooperativem  Multitasking
     andere  Prozesse  zum  Zug  kommen zu lassen. Bei der GEM-Version
     werden z.B. an dieser Stelle Events bearbeitet, die zwischendurch
     angefallen sind.

   . void unregistered_copyright ( void )
     Wird nicht mehr unterstuetzt. Falls der Linker eine Fehlermeldung
     ausgeben sollte, sollte man einfach eine leere Funktion einbauen,
     wie dies auch in cli.c gemacht wird.

   . void cursor_working ( void )
     Hier sollte man den Mauszeiger als Biene oder Sanduhr darstellen,
     um dem Benutzer anzuzeigen, dass UDO gerade am Werkeln  ist.  Bei
     textorientierten Oberflaechen ist diese Routine leer ausgelegt.

   . void cursor_active ( void )
     Hier  sollten  Funktionen  eingebaut  werden,  um  den Mauszeiger
     wieder als Pfeil darzustellen.

   . BOOLEAN break_action ( void )
     Die Routine sollte  TRUE zurueckgeben,  falls  der  Benutzer  den
     Uebersetzungsvorgang   abgebrochen   hat.   In   der  GEM-Version
     geschieht dies durch gleichzeitiges Druecken beider  Shifttasten.
     Textorientierte Oberflaechen sollte immer FALSE zurueckgeben.



8  Distribution vorbereiten
***************************


8.1  Makefiles
==============

Den Sourcecodes  liegen  vorgefertigte  Makefiles  bei,  die  man  zur
Compilierung verwenden sollte. Hier die  passenden  Make-Aufrufe  fuer
die  verschiedenen  Systeme,  nachdem man das passende Makefile in das
Quelltextverzeichnis kopiert hat:

 BeOS:   make -f makefile.bos

 DOS:    make -f makefile.emx

 HP-UX:

         Hier muss  das  Makefile  abhaengig   vom   zu   verwendenden
         Zeichensatz  gewaehlt  werden.  Vor einem Make sollte man die
         alten Objectfiles loeschen (make clean):

          ISO Latin 1:  make -f makefile.hpi
                        es wird udo-iso erzeugt.

          Roman 8:      make -f makefile.hp8
                        es wird udo-hp8 erzeugt.

 Linux:  make -f makefile.lin

 NeXT:   make -f makefile.nex

 Sinix:  make -f makefile.snx

 SunOS:  make -f makefile.sun


8.2  Doku und Manualpage umwandeln
==================================

Nachdem UDO compiliert wurde, sollte man  die  Dokumentation  und  die
Installationsanweisungen ins ASCII-Format umwandeln und die Manualpage
erzeugen:

$ cd ger/manual
$ udo -o udo.txt udo.u
$ udo -o install.txt install.u
$ udo -o news.txt news.u
$ udo --man -o udo.man manpage.u
$ udo --nroff -o udo.1 manpage.u
$ cd ../../eng/manual
$ udo -o udo.txt udo.u
$ udo -o install.txt install.u
$ udo -o news.txt news.u
$ udo --man -o udo.man manpage.u
$ udo --nroff -o udo.1 manpage.u

Danach hat man also - jeweils in deutscher und  englischer  Sprache  -
folgende Dateien erhalten: udo.txt, install.txt, news.txt, udo.man und
udo.1. Diese werden gleich benoetigt.


8.3  FILE_ID.DIZ anpassen
=========================

In manual/ befinden sich die Dateien file_id.diz und  file_id.ger.  In
diesen   Dateien   muessen  noch  das  jeweilige  Betriebssystem,  die
Releasenummer und das Datum angepasst werden.

Nein, UDO gibt es nicht fuer den ZX Spectrum ;-)


8.4  Archiv erstellen und packen
================================

UDO und die Anleitungen sind  nun  komplett.  Bitte  erzeugt  auf  den
Unix-Systemen Archive mit folgendem Aufbau:

UDO6G???.TAR.GZ:

copying.ger
copying.eng
file_id.diz
bin/udo
doc/examples/*    ( <-- ger/examples/* )
doc/formular/*    ( <-- ger/formular/* )
doc/install.txt
doc/news.txt
doc/udo6ger.txt
man/man1/udo.1    ( <-- ger/manual/udo.man)
man/cat1/udo.1    ( <-- ger/manual/udo.1)


UDO6E???.TAR.GZ:

copying.ger
copying.eng
file_id.diz
bin/udo
doc/examples/*    ( <-- eng/examples/* )
doc/formular/*    ( <-- eng/formular/* )
doc/install.txt
doc/news.txt
doc/udo6eng.txt
man/man1/udo.1    ( <-- eng/manual/udo.man)
man/cat1/udo.1    ( <-- eng/manual/udo.1)

Auf den    anderen    Systemen    (MacOS)    sollte   eine   aehnliche
Verzeichnisstruktur gewaehlt werden.

Wichtig: Das  Binary  sollte  zuvor  gestripped  werden,  da  in   den
Makefiles grundsaetzlich mit Debuginformationen compilert wird!

In das  Archiv  sollten  nicht die Quelltexte der Doku gepackt werden!
Die Quelltexte werde ich in ein spezielles Archiv packen und uploaden,
da sie fuer alle Betriebssysteme gleichsam verwendet werden koennen.

Nachdem die  obige  Verzeichnisstruktur  erstellt  wurde, packt Ihr es
bitte mit dem auf  dem  System  gebraeuchlichsten  Packer.  Auf  Unix-
Systemen  sollten  Tar-Compress-Archive  bzw. Tar-GZip-Archive benutzt
werden.



