Institut

Studium

Forschung


 

Arbeiten mit Festival Quellcode


Anlegen einer lokalen Festivalkopei mit cvs checkout

  1. Um das CVS Verzeichnis zu definieren, muß die Environment Variable CVSROOT gesetzt werden:

  2. für csh, tcsh sollte folgende Zeile in .cshrc stehen:
    setenv CVSROOT /mount/cvs-repository
    für sh, bash in .profile oder .bash:
    CVSROOT=/mount/cvs-repository
    export CVSROOT
  3. Festival auschecken. Dieser Befehl erzeugt eine lokale Kopie des Festival-Pakets:

  4. cd ~
    cvs checkout Festival_1.4/festival
    cvs checkout Festival_1.4/Makefile
  5. Der Quellcode der Festival speech_tools wird im allgemeinen nicht benötigt. Deshalb wird die lokale Festivalkopie über einen Link mit einer aktuellen speech_tools-Version verbunden. Lexika und Stimmen sind ebenfalls nur einmal vorhanden. Der folgende Befehl verbindet auch sie durch Links:

  6. cd Festival_1.4
    make links-speech_tools
  7. Möchte man dennoch eine eigene Version der speech_tools besitzen, so muß diese ebenfalls ausgecheckt werden:

  8. cd ~
    cvs checkout Festival_1.4/speech_tools


Kompilieren von Festival

  1. Besitzt man eine  eigene Version der speech_tools, so muß diese zuerst compiliert werden. Im andern Fall entfällt dieser Schritt:

  2. cd ~/Festival_1.4/speech_tools
    gmake
  3. Kompilieren von festival:

  4. cd ~/Festival_1.4/festival
    gmake
  5. Kaffee trinken gehen (das Compilieren dauert eine gute halbe Stunde)


Kompilieren von Festival mit SmartKom-Modul

  1. die Datei ~/Festival_1.4/festival/config/config muss editiert werden, so dass smartkom_german mitkompiliert wird.
  2. Die entsprechende Zeile ist per Default auskommentiert. Sie muss lauten:

  3. ALSO_INCLUDE += smartkom_german
  4. Zum Kompilieren werden ausserdem spezielle SmartKom-Libraries benoetigt. Sie werden im Verzeichnis $SK_HOME gesucht. Diese Variable
  5. muss also entsprechend gesetzt werden, am besten z.B. in .cshrc:

  6. setenv SK_HOME /projekte/smartkom/Testbed/4.0
  7. Hat man keinen Zugriff auf /projekte/smartkom, sollte eine Kopie des gesamten lib Verzeichnis unter $SK_HOME ausreichen. Danach also kompilieren:

  8. cd ~/Festival_1.4/festival
    gmake
  9. Zur Laufzeit muessen folgende Verzeichnisse im LD_LIBRARY_PATH enthalten sein, am besten auch das in .cshrc:

  10. if ($?LD_LIBRARY_PATH == 0) then
    setenv LD_LIBRARY_PATH \  $SK_HOME/lib/pools/lib/:$SK_HOME/lib/sicstus/lib:$SK_HOME/lib/xerces/lib/:$SK_HOME/lib/m3l/lib:$SK_HOME/lib/adts/lib
    else
    setenv LD_LIBRARY_PATH \ $SK_HOME/lib/pools/lib/:$SK_HOME/lib/sicstus/lib:$SK_HOME/lib/xerces/lib/:$SK_HOME/lib/m3l/lib:$SK_HOME/lib/adts/lib:${LD_LIBRARY_PATH}
    endif


Verändern von Dateien und cvs commit

Veränderungen werden in der lokalen Kopie von Festival durchgeführt. Ist die Modifikation abgeschlossen, werden die Dateien wieder an CVS zurückgegeben (publiziert), und damit anderen Benutzern zugänglich gemacht. Hierbei können drei Fälle unterschieden werden:

  1. Ändern von existierenden Dateien

  2. Wenn eine Änderung publiziert werden soll, so wird diese mit folgendem Befehl in das CVS Repositorium übernommen:
    cvs commit filename(s)
    Ein ganzes Verzeichnis (samt Unterverzeichnisse) wird mit:
    cvs commit pathname
    übernommen. Wird der Pfadname weggelassen, so bezieht sich die Publikation auf das aktuelle Verzeichnis.
  3. Erzeugen von neuen Dateien

  4. Neue Dateien können in der lokalen Festivalkopie einfach erzeugt werden. Ist eine Änderung abgeschlossen, so werden die Dateien dem CVS folgendermaßen bekanntgegeben:
    cvs add filename(s)
    Danach wirden sie mit:
    cvs commit filename(s)
    übernommen.
  5. Löschen von Dateien.

  6. Wurden in der lokalen Kopie Dateien gelöscht, so wird dies dem CVS folgendermaßen mitgelteilt:
    cvs remove filename(s)
    Erst durch einen
    cvs commit filename(s)
    Befehl wird allerdings das Löschen im Repositorium durchgeführt. Solange ein Löschvorgang noch nicht mit cvs commit bestätigt worden ist, kann er in einfacher Weise durch
    cvs add filename(s)
    rückgängig gemacht werden.

Hinweis: Bevor Dateien an CVS übergeben werden, muß in der lokalen Festivalkopie eine einwandfreie Funktionsweise sichergestellt werden. Hierzu gehört auf alle Fälle, daß das lokale Festival ohne Fehler compiliert und gestartet werden kann. Weitergehende Tests sind sehr zu empfehlen.
Außerdem sollte jede Änderung des CVS der daran arbeitenden Personen bekannt gegeben werden (am besten durcxh eine kurze Mail).


Versionenkonflikt und cvs update

Beim Befehl cvs commit kann es passieren, daß ein Versionenkonflikt auftritt, wenn jemand anders an der gleichen Datei gearbeitet hat und diese bereits vorher wieder publiziert hat. Tritt dieser Fall auf, so endet cvs commit mit einer Fehlermeldung. In diesem Fall muß zunächst die lokale Festivalkopie aktualisert werden:
cvs update [filename(s)|pathname]
CVS versucht die aktuelle Version mit der lokalen Version zu verbinden (mittels eines "intelligenten" diffs). Ist dies möglich, so endet cvs update ohne Fehlermeldung und die nun aktualisierte lokale Version kann schließlich mit cvs commit pubiziert werden.

Nich immer endet cvs update ohne Probleme. Wenn ein anderer Entwickler z.B. and derselben Stelle im Quellcode gearbeitet hat, so muß der Konflikt manuell gelöst werden. In diesem Fall wird die alte lokale Datei (z.B.grummel), in der der Konflikt aufgetreten ist , von CVS automatisch unter .#grummel.x.y abgespeichert (x.y steht für die aktuelle Versionsnummer). Außerdem wird der Konflikt in der Datei grummel folgendermaßen in diff-Stil markiert:

<<<<<<< grummel
(Quellcode aus lokaler Kopie)
=======
(Quellcode aus CVS Distribution)
>>>>>>>

Der Konflikt wird gelöst, indem die Datei grummel editiert und an der markierten Stelle der Quellkode korrigiert wird. Hierbei müssen die Kontrollmarkierungen (<<<<<<<, =======, >>>>>>>) gelöscht werden. Danach kann die DAtei mit cvs commit entgültig publiziert werden.


cvs diff und cvs history

Um Informationen drüber zu erhalten, inwieweit der lokale Quellcode von der CVS Version abweicht ,kann der Befehl
cvs diff filename
angewandt werden.

Der Befehl
cvs history filename
informiert über Änderungen, die an einem File unternommen wurden.

Um die log-Informationen eines Files zu sichten gibt man
cvs log filename
ein.

Für weitere Informationen zu cvs sei der Befehl
man cvs
empfohlen.

 


Antje Schweitzer (anje.schweitzer@ims.uni-stuttgart.de)