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.
- 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.