Arbeiten mit Festival Quellcode
Anlegen einer lokalen Festivalkopei mit cvs checkout
- Um das CVS Verzeichnis zu definieren, muß die Environment Variable CVSROOT gesetzt werden:
- Festival auschecken. Dieser Befehl erzeugt eine lokale Kopie des Festival-Pakets:
- 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:
- Möchte man dennoch eine eigene Version der speech_tools besitzen, so muß diese ebenfalls ausgecheckt werden:
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
cd ~
cvs checkout Festival_1.4/festival
cvs checkout Festival_1.4/Makefile
cd Festival_1.4
make links-speech_tools
cd ~
cvs checkout Festival_1.4/speech_tools
Kompilieren von Festival
- Besitzt man eine eigene Version der speech_tools, so muß diese zuerst compiliert werden. Im andern Fall entfällt dieser Schritt:
- Kompilieren von festival:
- Kaffee trinken gehen (das Compilieren dauert eine gute halbe Stunde)
cd ~/Festival_1.4/speech_tools
gmake
cd ~/Festival_1.4/festival
gmake
Kompilieren von Festival mit SmartKom-Modul
- die Datei ~/Festival_1.4/festival/config/config muss editiert werden, so dass smartkom_german mitkompiliert wird.
- Die entsprechende Zeile ist per Default auskommentiert. Sie muss lauten:
- Zum Kompilieren werden ausserdem spezielle SmartKom-Libraries benoetigt. Sie werden im Verzeichnis $SK_HOME gesucht. Diese Variable
- muss also entsprechend gesetzt werden, am besten z.B. in .cshrc:
- Hat man keinen Zugriff auf /projekte/smartkom, sollte eine Kopie des gesamten lib Verzeichnis unter $SK_HOME ausreichen. Danach also kompilieren:
- Zur Laufzeit muessen folgende Verzeichnisse im LD_LIBRARY_PATH enthalten sein, am besten auch das in .cshrc:
ALSO_INCLUDE += smartkom_german
setenv SK_HOME /projekte/smartkom/Testbed/4.0
cd ~/Festival_1.4/festival
gmake
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:
- Ändern von existierenden Dateien
- Erzeugen von neuen Dateien
- Löschen von Dateien.
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.
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.
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.