Wie installiere ich Software für module?

Die Installation von Software für module erfordert, dass man einige Feinheiten beachtet, die sich aus

ergeben. Gott sei dank benutzen fast all Softwareentwickler heutzutage GNU automake basierte Installationsmechanismen, so dass die Installation gut geschriebener Software (leider keine Selbstverständlichkeit) nahezu automatisiert ablaufen kann.

Standard Installation

Im Folgenden beschreibe ich die Installation des Programmpaketes xxx in der Version a.bb.

  1. Als erstes gilt es, die entsprechenden Quellen runterzuladen. Im folgenden gehe ich davon aus, dass ein Tar-File mit dem Namen xxx-a.bb.tgz im Verzeichnis /software/inst liegt. Das Verzeichnis /software/inst ist World-Writeable; von daher ist es Ratsam, die Integrität der Quellen direkt vor der Installation noch einmal zu überprüfen. Viele Pakete bieten dazu eine separate pgp-Signatur xxx-a.bb.tgz.asc oder eine MD5sum an.
  2. Als nächstes gilt es, das Archiv zu entpacken und ihm einen kanonischen Namen (src) zu geben
    kogs1>/home/utcke% mkdir /software/xxx-a.bb
    kogs1>/home/utcke% cd /software/xxx-a.bb
    # pack das Tar-file aus, normalerweise nach /software/xxx-a.bb/xxx-a.bb
    kogs1>/software/xxx-a.bb% gtar -xzvf ../inst/xxx-a.bb.tgz
    # benenne das gerade erzeugte Verzeichnis um
    kogs1>/software/xxx-a.bb% mv * src
  3. Jetzt gilt es, die Installationsanweisungen zu lesen, in aller Regel in src/INSTALL oder, vermehrt, in src/README. Wenn es sich um ein standard autoconf/automake Paket handelt, dann wird das folgende Skript das Paket für den jeweiligen Maschinentyp installieren:
    #!/usr/bin/tcsh -f

    set symlinks=expand

    module purge
    # Hier kann man Module laden, die das Programm benötigt
    # module add zlib libpng-1.2 ...

    set PLATFORM=`/software/Modules/bin/platform`
    set DIR=`pwd`
    set PKG=$DIR:t

    # Falls das Programmpaket dies unterstützt, kann man für mehrere
    # Platformen gleichzeitig übersetzen.
    mkdir -p $PLATFORM/objs
    cd $PLATFORM/objs

    make distclean

    $DIR/src/configure --prefix=$DIR --exec-prefix=$DIR/$PLATFORM --disable-rpath |& tee /tmp/$PKG-conf.$$

    make |& tee /tmp/$PKG-comp.$$
    if ( $? == 0 ) then
      make check |& tee /tmp/$PKG-check.$$
      if ( $? == 0 ) then
        make install |& tee /tmp/$PKG-inst.$$
        if ( -d $DIR/include ) then
          ln -s $DIR/include $DIR/$PLATFORM/include
        endif
      endif
    endif

    Den obigen Code kann man hier runterladen, er sollte unter dem Namen /software/xxx-a.bb/build gespeichert werden; im idealen Fall muss man das Skript pro Plattform einmal laufen lassen (kann zeitgleich geschehen):
    kogs1>/software/xxx-a.bb% source build
    und das Programm ist fertig installiert. Aktuell existieren die folgenden Plattformen; dahinter ist jeweils der Name der Maschine genannt, auf der man übersetzen sollte:
    Plattform Maschine
    SunOS-5.8 kogs2
    SuSE-9.0 kogspc2
    SuSE-10.0 kogspc30

Mögliche Probleme

Soweit der ideale Ablauf. Im wirklichen Leben werden aber mit Sicherheit eine Reihe von Problemen auftreten, und da heutzutage Probleme auf einer SUN wahrscheinlicher sind als auf einem Linux-Rechner, bietet es sich an, zuerst einmal nur auf der kogs2 zu übersetzen. Dabei kann es dann zum Beispiel zu den folgenden Problemen kommen:
file not found oder ähnliche Fehler
Das Programmpaket muss im src Verzeichnis selber kopiert werden; dazu ändert man die Zeilen
# Falls das Programmpaket dies unterstützt, kann man für mehrere
# Platformen gleichzeitig übersetzen.
mkdir -p $PLATFORM/objs
cd $PLATFORM/objs
in
# Das Programmpaket unterstützt es nicht, für mehrere
# Platformen gleichzeitig zu übersetzen.
mkdir -p $PLATFORM
cd src
ACHTUNG: dann kann man immer nur auf einem Rechner zur Zeit übersetzen!
Abhängigkeiten von anderen Programmen / Bibliotheken
Oft hängt ein neu zu installierendes Programmpaket von anderen Programmen oder Bibliotheken ab; diese Programme sollten dann als module geladen werden. Manchmal sind das harte Abhängigkeiten, und der configure Prozess bricht schlicht ab, wenn er die Programme nicht findet; in vielen Fällen sind es jedoch weiche Abhängigkeiten, das Paket compiliert also trotzdem, ihm fehlen aber einige (viele) Fähigkeiten. Um festzustellen, von welchen Programmen und Bibliotheken ein neu zu installierendes Programmpaket abhängt, gibt es im wesentlichen zwei Möglichkeiten:
  1. /software/xxx-a.bb/src/README und /software/xxx-a.bb/src/INSTALL studieren.
  2. Der build Prozess legt eine Datei /tmp/xxx-a.bb-conf.* an, die alle Bibliotheken und Programme auflistet, nach denen gesucht wurde (und auch welche, eventuell veralteten, Versionen gefunden wurden).
All diese Abhängigkeiten sollten direkt nach dem module purge in das build Skript eingetragen werden.
Weitere configure Optionen
In manchen Fällen muss das Software-Paket noch an die Gegebenheiten bei KOGS angepasst werden; dies wird in aller Regel über bestimmte Optionen erreicht, die man an das configure Skript übergibt. Welche Optionen da class=prg>in Frage kommen, erfährt man durch das Studium von /software/xxx-a.bb/src/README und /software/xxx-a.bb/src/INSTALL oder durch den Aufruf von
kogs1>/software/xxx-a.bb% src/configure --help

Nachdem der Installationsprozess auf der kogs2 reibungslos durchläuft, kann man sich dann auch an die anderen Plattformen machen; Erfahrungsgemäß werden auf den Linux-Rechnern jetzt keine weiteren Probleme mehr auftauchen.

Module

Nachdem die Software nun für alle Plattformen installiert ist, gilt es als nächstes, entsprechende Beschreibungen für module zu schreiben, ein so genanntes Modulefile. Modulefiles sind in Tcl geschrieben, ein klassisches Modulefile sieht z.B. so aus:

#%Module1.0#####################################################################
##
# Diese Datei wird von einem Tcl Interpreter gelesen.
# Mehr Informationen bekommt man mit
#
# module add modules
# man modulefile
#

set PLATFORM [exec /software/Modules/bin/platform]

# Dieser Text wird bei 'module help' angezeigt. Typische Quellen sind
# die ersten paar Zeilen der man-pages, des info-files oder der
# README. Sinn dieses Blocks ist es zu erklären was das Programm
# macht und wie man es benutzt.
proc ModulesHelp { } {
  puts stderr "\tThe XXX is the foo bar Manipulation Program, a layer-capable,"
  puts stderr "\tPhotshop(TM)-like software for such tasks as photo retouching, image"
  puts stderr "\tcomposition and image authoring. It works on many operating systems,"
  puts stderr "\tin many languages.\n"
}

# Dieser Text wird bei 'module whatis' angezeigt. kann maximal 56
# Zeichen lang sein. Eine gute Quelle ist die kurz-Beschreibung aus
# den man-pages.
module-whatis "the GNU foo bar Program."

# Module, die nicht gleichzeitig geladen werden können. Jedes Modul
# hat normalerweise mindestens einen Konflikt mit anderen Versionen
# des gleichen Moduls
conflict xxx

# Include-Datei, in der all KOGS::* Funktionen definiert sind ---
# sollte nur geladen werden, wenn man sie auch braucht!
source /software/Modules/lib/KOGS.tcl

# Abhängigkeiten. Ein guter Startpunkt sind die Module, die zur
# Compile-Zeit (vom build Skript) geladen waren. Genaueres (und man
# sollte das so genau wie möglich machen) findet man mit
#
# ldd /software/xxx-a.bb/$PLATFORM/bin/* | sort -u
#
# raus
KOGS::dep zlib
# falls bestimmte Versionen benötigt werden (letzte ist default):
KOGS::dep qt-3 {2.3 3.3}

# Environment Variabeln. Natürlich sollten nur die gesetzt werden,
# die es auch gibt.
prepend-path PATH /software/xxx-a.bb/$PLATFORM/bin
prepend-path LD_LIBRARY_PATH /software/xxx-a.bb/$PLATFORM/lib
prepend-path MANPATH /software/xxx-a.bb/man
prepend-path INFOPATH /software/xxx-a.bb/info
prepend-path PKG_CONFIG_PATH /software/xxx-a.bb/$PLATFORM/lib/pkgconfig
KOGS::prepend-flags CPPFLAGS -I/software/xxx-a.bb/include
KOGS::prepend-flags LDFLAGS -L/software/xxx-a.bb/$PLATFORM/lib
# Alternativ kann man auch die (zur Zeit noch experimentelle) Funktion
#
# KOGS::scan-prefix /software/xxx-a.bb
#
# verwenden, die PLATFORM und alle obigen Variablen setzt.
Den obigen Code kann man hier runterladen. Nachdem alle entsprechenden Änderungen eingearbeitet wurden, kann man die Datei unter /software/Modules/SunOS/modulefiles/xxx/a.bb speichern und noch einmal unter /software/Modules/Linux/modulefiles/xxx/a.bb verlinken, so dass die gleiche Datei sowohl für Linux als auch für Solaris genutzt werden kann.

Als letztes sollte man noch einen Test durchführen, ob das Modulefile wirklich alle Abhängigkeiten berücksichtigt:

# Alle Module entladen.
kogs1>/home/utcke% module purge
# Das neue Module testen:
# Funktioniert die Hilfe?
kogs1>/home/utcke% module help xxx
# Funktioniert die Kurzbeschreibung?
kogs1>/home/utcke% module whatis xxx
# Funktioniert das Module?
kogs1>/home/utcke% module add xxx
kogs1>/home/utcke% xxx
# Fehlen wirklich keine Abhängigkeiten?
kogs1>/home/utcke% ldd /software/xxx-a.bb/$PLATFORM/bin/* | sort -u | grep "file not found"

Wenn jetzt alles geklappt hat, dann sollte man ganz zum Schluss noch das frisch installierte Paket in /software/DONE eintragen und von Zeit zu Zeit die dort eingetragenen Pakete an kogs-alle mailen.

Sven Utcke

Valid HTML 4.0! Valid CSS!

last modified: 11-Aug-2006