Autor: Christian Bttger cb@openxp.de, 2003-10-18

Hier der Ablauf fr die build scripts:

(workdir ist hart kodiert auf /home/boettger/openxp/, die Versionen liegen in
/home/boettger/openxp/3.8/openxp/ bzw /home/boettger/openxp/3.9/openxp/ )

mkdailysnap
    |
    +--- snapshot (Parameter 3.8 oder 3.9)
         |
         +--- cvs up -C version.inc;
         |    ./inc_build_nr.pl;
         |    eval $(./get_build_nr.pl)
         |    
         +--- buildxp
         |    |
         |    + eval $(./get_build_nr.pl)
         |    |
         |    +--- makexp
         |         |
         |         + eval $(./get_build_nr.pl)
         |         
         +--- make-rpm.sh
              |
              + eval $(./get_build_nr.pl)

mkdailysnap:
 prft per diff, ob sich im CVS gegenber -1Day was gendert hat, wobei
  nderungen an version.inc ignoriert werden
 luft als root, wird von cron aufgerufen

snapshot:
 wird mit Parameter 3.8 oder 3.9 aufgerufen, um ins passende workdir
  gehen zu knnen
 holt die version.inc aus dem CVS
 erhht version.inc durch Aufruf von inc_build_nr.pl
 schiebt die neue version.inc ins CVS
 geht ins fr die Version passende workdir
 ruft buildxp auf
 prft, ob ein openxp binary erzeugt wurde, falls nein: exit
 falls ja, ruft es make-rpm.sh auf
 packt ein source tarball als tar.bz2
 schiebt die Ergebnisse auf den ftp server
 setzt die file owner wieder von root auf den owner des workdir
 luft als root, wegen make-rpm.sh

buildxp:
 muss im workdir der gewnschten Version aufgerufen werden
 holt sich die Parameter mit get_build_nr.pl
 lscht alle alten .o, .ppu etc
 macht ein cvs up mit zur Version (3.8 oder 3.9) passendem -r Parameter
 ruft makexp auf
 prft, ob binaries erzeugt wurden
 falls nein: verschickt die Fehlermail an die cvs-Liste mit passend
  zusammengebautem Subject
 ruft rc und ihs auf
 falls binaries da sind, packt es die binary tarballs
 kann als normaler user laufen

makexp:
  muss im workdir der gewnschten Version aufgerufen werden
  holt sich die Parameter mit get_build_nr.pl
  setzt passend zur Version (3.8 oder 3.9) die fpc Optionen
  ruft fpc und Kylix auf fr openxp
  kann das binary mit upx packen   
  stellt die Logfiles fr fpc und Kylix in Archiven zusammen   
  ruft fpc auf fr rc und ihs
  kann als normaler user laufen

make-rpm.sh:
  muss im workdir der gewnschten Version aufgerufen werden
  holt sich die Parameter mit get_build_nr.pl
  legt ein temp-workdir an
  checkt die Quellen der gewnschten Version (3.8 oder 3.9) aus
  packt daraus das source tarball fr rpm
  und schiebt es nach /usr/src/packages/SOURCES/ mit richtigem Dateinamen
  lscht das tmp-workdir
  ruft rpm -ba auf mit zur Version passendem .spec
   (das benutzt dann den tarball aus /usr/src/packages/SOURCES/ und baut
    daraus .src.rpm und .i386.rpm)
  muss natrlich als root laufen  

get_build_nr.pl:
 holt aus version.inc und xpglobal die Versionsnummern
 setzt die ENV Variablen OPENXP_MAINVER, OPENXP_SUBVER und OPENXP_BUILD,
  die dann von allen Skripten benutzt werden, um die Dateinamen richtig 
  zusammen zu bauen, in die richtigen Verzeichnisse zu wechseln und das 
  Subject der Fehlermeldung zusammen zu bauen
 erzeugt mit richtigem Dateinamen und Inhalt ein passendes .spec
   dafr wird openxp.spec als Template genommen

inc_build_nr.pl:
 inkrementiert die Versionnummer und erzeugt ein neues version.inc

Es sind mehrere Skripte, damit man die Teile des Prozesses auch halb-
manuell unabhngig durchfhren kann: makexp, um nur ein neues Binary zu
bauen; buildxp, um auch neue rc und ihs Ergebnisse zu haben und Fehler 
an die Liste zu schicken; snapshot um einen snapshot auch manuell
anstarten zu knnen (manchmal hngt sich der cron weg, vermutlich immer
dann, wenn T-Online dem Rechner whrend des Laufes den tglichen Kick  
verpasst). Da sich alle Skripte aus Konsistenzgrnden die Parameter fr
die Version aus get_build_nr.pl holen, darf dieses Skript die
Versionsnummer nur auslesen, nicht aber neu setzen. Dafr ist inc_
zustndig, das nur aufgerufen wird, wenn auch tatschlich ein snapshot
gebaut wird.

