Constraints to Build and Rollout of Device Access using Maven and SCons

Information: How to work with Maven/Scons

Beispiele für typische Aufgaben

• Geräte-SW (weiter-)entwickeln
  Code erstellen / ändern, und diesen compilieren
  in Testrahmen ausprobieren
  freigeben für allgemeine Benutzung
• zusätzliches Gerätemodell auf einen Produktions-VME-Rahmen bringen
  Gerätemodell hat jemand vor einem halben Jahr erstellt
• upgrade Geräte-SW auf neue Version auf einem, auf sieben oder auf allen Produktionsrahmen
  upgrade DevMan auf einem, sieben oder allen Produktionsrahmen
• Nameserver-exe ist versehentlich gelöscht - wie erzeuge ich ein neues?
• neues Release der FE-SW erstellen

Was ist noch zu tun?

Allgemein

• Quellen in C++, Java und Python
• Plattformen x86_64, i386 und ppc.
• Plattform Linux; Windows wird nicht mehr unterstützt!
• Schnittstellen mit AP
  • die brauchen Header und Libs von uns -> das sind maven artefakte
  • wir brauchen Header, Libs und Tools (msgc) von ihnen
• Der msgc ist eigentlich ein Tool, das man erst bauen müsste, um es dann benutzen zu können. Er ist nicht per se auf einer jungfräulichen Plattform vorhanden. -> Der msgc ist auch ein Artefakt. Es gibt aber eine Kreisabhängigkeit zwischen cscoap und cscofe, d.h. ohne Artefakt Repository könnte man auch nicht loslegen.

Framework

• Generieren auch für x86_64.

Gerätemodelle

Bei den Sonderlösungen unter den Gerätemodellen (MD0, MX0, FGnn, ...) muss man sicher noch mal genauer überlegen, wie man das unter Maven am besten löst.

• Generierung und Rollout von z.B. MX, MX0 und MXS aus einem Projekt, wobei es zum Teil (MX0) Sonderlösungen beim Generieren und Rollout gibt.
• Generierung der Python-Stubs aus <EqModel>.xml, auch hierunter Berücksichtigung von z.B. MX, MX0, MXS. Dito mit Sonderlösungen beim Generieren und Rollout.
• Rollout der Python-Stubs mit dem Problem, dass man mehrere Python-Stubs parallel in einem Verzeichnis halten muss, also z.B. MX_21EqMod.py und MX_22EqMod.py.
• Generierung und Rollout der XMLs aus <EqModel>.xml, dito für z.B. MX, MX0, MXS inklusive Sonderlösungen
• Build/Rollout von M68k-ECM und -EQMs.
• ECM generieren für 2 Hardware-Boards (F, G).
• EQMs können Varianten haben. Also Generierung und Rollout von z.B. MX-Var1-EQMs bis MX-VarN-EQMs aus einem Projekt.

EqModWrapper

Gerätemodell-spezifische Python-Skripte für PropHelper zur Verschönerung seines Outputs.

• Wohin mit den Quellen? Zum Gerätemodell oder alle in eine xtra Projekt?
• Rollout wohin?

Message-Dateien

• Generierung der Message-Header aus *.msg und der Bibliothek(en)
• Evtl. alle *.msg-Quellen in einem Verzeichnis, separat von den Gerätemodellen. Gerätemodelle erhalten eine Abhängigkeit auf dieses Projekt. Beim Bauen des message-Projektes werden alle zusätzlichen Ausgabeformate für JAVA, Python, etc) mit erstellt.
• Evtl. zusammen mit AP inklusive FESA und Co.

Tools

• Rollout von z.B. devstatus.py, conndesc.py usw.

PPC-GuPs

• Boot-Skript pro GuP (mit RAM-Disk).
• wo geht dann eigentlich bei Programmabsturz der core-dump hin?

SE-Software

• SR-Dateien *.sr werden auf SE-Directory gelegt und von dort vom GuP geholt und an die SE geschickt. Bei GuPs mit RAM-Disk geht das so (einfach) nicht mehr.

---

Was tun DevAcc 'gen'- und 'rel'-Skripte zur Zeit?

Viele Skripte liefern mit <script> -H ein ausführliches Help.

In $uti

* genmsg.sh
  Message-Datei kompilieren und Message-Lib updaten.
  Message-Lib ist release-unabhängig!

* pygen.sh
  Generiere USR-Python-Sources aus <eqmod>_complete.xml
  Ist eigentlich release-abhängig.

In $utiasl

* gendevacc.py (und gendevacc.*-Helper)
  Neues Komplett- oder Teil-Release erstellen in
  $PROOT/[build|libppc|lib|lib64]|incvme|incasl|python]/<release>

* protdevacc.py
  Releaste Directories schreibschützen

* reldevacc.py
  Release zur Default-Release machen.
  Links 'current'auf libppc|lib|lib64]|incvme|incasl|python
  umsetzen.

* reldevman.py
  Devman und libs für einen GuP releasen.
  Link 'library' auf GuP-Directory /opt/acc/cpu umsetzen.

* relnameserver.py
  Nameserver releasen.
  Link 'library' auf asl-Directory $PROOT/nameserver
  umsetzen.

* relufcserver.py
  UfcServer releasen.
  Link 'library' auf asl-Directory $PROOT/ufcserver
  umsetzen.

In $utivme

* copyusrs
  USRs testweise auf einen GuP kopieren (statt relusrs).
  USRs auf privates <eqp>-Directory kopieren und Link
  '<eqmod>.so' auf GuP-Directory /opt/acc/cpu umsetzen
  auf diese Datei.

* dbscopy.py
  Kopiere <GuP>.dbs-File auf GuP-Directory /opt/acc/cpu.

* dbsgen
  <GuP>.dbd + DB-Polynome -> <GuP>.dbs

* ecload.py
  Lade ECM/EQM-sr-Datei auf eine SE. Geht in der Regel davon
  aus, dass die Datei auf dem entsprechenden SE-Verzeichnis
  liegt. Der GuP bekommt also nur den Namen der Datei.
  Direktes laden der Datei über das Skript ist sehr langsam!
  Liegt das an Python?

* ecmlinkcreate
  Baue ECM/EQMs-Link-Directive. Wird von prepmakeeqms
  und releqms aufgerufen.

* geneqms.py
  Generiere USRs mit Quellen aus SVN/frontend/tags

* geneqmvariants
  Alle angegebenen EQM-Varianten eines Gerätemodelles
  generieren.

* genusrs.py
  Generiere USRs mit Quellen aus SVN/frontend/tags

* getvmedirs
  Setzt VME-Produktionsverzeichneisse in Umgebungsvariablen.

* prepmakeqms
  Generates the necessary files to build (compile, link)
  M68k-based EQMs for an equipment model using the
  configuration in vme.cfg. Called by vmeconfig.py via
  prepmake.

* prepmakeusrs-v09
  Generates the necessary files to build (compile, link)
  PPC- or X86-based USRs for an equipment model using
  the configuration in vme.cfg. Called by vmeconfig.py
  via prepmake.

* relecm
  Release an ECM.

* releqms
  Release EQMs generally or for a specific EC.

* relpy.py
  Release Python EqMod class file. Usually done in
  relusrs-v09.

* relusrs-v09
  Release USRs generally or for a specific GuP. It
  - releases a specific version of equipment model USRs,
  - releases the correspondig XML file (see also relxml.py),
  - releases the correspondig Python EqMod class file (see
    also relpy.py).

* relxml.py
  Release USR XML file.

* tagexists
  Ask subversion if tag exists for module.

* update_usrsv09.py
  Durchsucht alle GuP-Verzeichnisse /opt/acc/cpu nach dem
  angegebenen Gerätemodell und erstellt ein Skript zum Update
  der USRs auf allen GuPs.

* vmeconfig.py
  Erzeugt die notwendigen Skripte zum generieren von ECM,
  EQMs oder USRs. Ruft 'prepmake*' auf

Allgemein

Generierung:
- vmeconfig/make: vom lokalen Workspace
- gen...: aus SVN auf $PROOT/build bzw. auf ~/eqmod-gen
- genmsg: ist noch ein Problem

Release:
- Step 1: Allgemeine Release auf $PROOT/lib bzw. auf
          .../eldk/.../opt/acc/eqp
- Step 2: Spezielle Release für einen GuP oder eine SE.
          reldevman, relnameserver und relufcserver
          haben nur Step 2.