User Tools

Site Tools


de:doc:lua_make

This is an old revision of the document!


Die LUA Make Umgebung

Wie ist die Make Umgebung aufgebaut?

Die Umgebung wurde erstellt, um die folgenden Bedingungen zu erfüllen:

  • Handhabung von verschiedensten Fahrzeugbaureihen, jede mit Duzenden von Modulspezifikationen und Skripten.
  • Stapelübersetzung von XML Modulspezifikationen , handgeschriebenen Skripten und anderen Vorlagen in einem einzigen Schritt
  • Automatische Verschlüsselung der erzeugten Skripte, falls gewünscht

Um dies zu unterstützen, wird die gleiche Art der Arbeitsumgebung benutzt, wie sie in der Softwareentwicklung weitläufig bekannt ist: Eine Kommandozeilen basierte Schnittstelle, in der die verschiedenen Arbeitsschritte gestartet werden und durch sogenannte Makefiles, Skripte und andere eingebauten Werkzeuge kontrollliert werden können.

Das bedeutet das alle Schritte, durch das Tippen des entsprechenden Kommandos und seiner Parameter in die Kommandozeile, gestartet werden können.

Einrichten der Cygwin Laufzeitumgebung

Um die wesentlich mächtigere UNIX Umgebung zu nutzen, anstelle einer sehr einfachen DOS Kommandozeile, musst Du zunächst das CygWin Runtime Environment installieren. Um dies zu tun, folge bitte den CygWin Installationsinstruktionen

Basiswissen über die Cygwin Laufzeitumgebung

Nach dem Installieren und Starten von CygWin, wird Dir eine DOS ähnliche Kommandozeile dargeboten, mit einigen Unterschieden zu dieser:

  • Unix achtet auf Gross- und Kleinschreibung, deshalb muss alles immer korrekt geschrieben werden.
  • Die Basikommandos sind unterschiedlich zu denen, die Du von DOS/Windows her kennst. Eine gute Einführung in die Thematik kann unter http://mally.stanford.edu/~sr/computing/basic-unix.html gefunden werden
  • Unix benutzt in diesem speziellen Bereich keine Backslashes \ in Pfaden, es benutzt anstelle dessen einen normalen slash /
  • Unix kennt keine Laufwerksbuchstaben wie C:\. Anstelle jedes Laufwerkes und Verzeichnisses gibt es einen Unterordner unter dem globalen Wurzelverzeichnis “root” /cygdrive. So wird aus dem Laufwerk C:\ dann /cygdrive/c/, dein Desktopverzeichnis wird dann /cygrive/c/Users/yourusername/Desktop heissen (Achte auf die Gross- und Kleinschreibung!)
  • mit den Pfeiltasten kannst Du in der Historie der eingegebenen Kommandos blättern. Sehr hilfreich kann auch ohne dass komplette Abtippen des Kommandos die
  • TAB Taste sein mit der Kommandos und Dateinamen automatisch komplettiert werden.
  • Sehr wichtig! Unix Textdateien haben einen anderen Ende-der-Zeile Kennzeichner als Windows. Deshalb stelle bitte immer sicher, wenn Du Dateien ertellst oder editierst, das alle die Dateien im “Unix Line feed UTF8 without BOM” Format abgespeichert werden.

Verbinde dich selbst mit dem zentralen Skripte-Aufbewahrungsort (engl. Repository)

Sobald mehrere Skripte beibehalten werden müssen oder mehr als eine Person auf den Skripten arbeiten, ist es sehr empfehlenswert, ein zentrales Skript-Repository zu verwenden, wie wir es hier in unserem Beispiel mit einem zentralen Subversion Server tun. Die Nutzung von Subversion als solches fällt nicht in den Anwendungsbereich dieses Dokuments, aber Du wirst Tonnen von Unterlagen im Internet zu diesem Thema finden. Bitte lies einige Basis-Tutorials durch die Dir ein grundlegendes Verständnis über Subversion vermitteln.

Um sich mit dem sogenannten “Repository” zu verbinden nehme bitte Kontakt mit dem Repositoryadministrator (S.K.) auf. Von Ihm erhältst Du die sogenannte Repository-URL, deinen Nutzernamen und dein Passwort.

Als nächstes erzeuge ein leeres Verzeichnis, in dem Du deine Skripte z.B auf dem Desktop speichern möchtest

cd /cygdrive/c/Nutzer/deinNutzername/Desktop
mkdir OOBD-Script-Repository
cd OOBD-Script-Repository

als nächstes erzeuge eine sogenannte “lokale Arbeitskopie” des Repositorys mit dem Kommando

svn checkout Repository-URL

Du wirst nach deinem Nutzernamen und deinem Passwort gefragt und dann transferiert SVN (die Abkürzung für Subversion) das komplette Repository in dein Arbeitsverzeichnis.

Du wirst später vielleicht feststellen das eine Menge von .svn Verzeichnisse erzeugt worden sind. In diesen speichert Subversion Metadaten für die Wartung. Bitte lösche oder verändere diese Verzeichnisse nicht!

Der Verzeichnisbaum

Um die verfügbaren Werkzeuge für OOBD zu nutzen, ist es wesentlich das Du die Datenstruktur so beläßt wie sie ist, weil die Werkzeugeinstellungen darauf beruhen.

Nach dem Beenden des initialen Auscheckens, findest Du einen Verzeichnis- und Datenstruktur wie folgt vor:

.
+-- ...
+-- lua
+-- mdx_pool
+-- oobd_groups.pub
+-- oobd_groups.pub.sig
+-- tools

So, wofür ist dies nun alles gut?

Das mdx_pool ist das Verzeichnis, in dem alle XML Module abgespeichert werden können, immer nach der Bezeichnung FahrzeugBaureihe_ModellJahr_Modulkurzname

Das tools Verzeichnis beinhaltet alle Programme und Skripte die für OOBD notwendig sind. Der erfahrene Nutzer möchte vielleicht wissen das einige der Unterverzeichnisse als sogenannte “svn:external” zu anderen Repositorys verbunden sind.

Das oobd_groups.pub ist ein pgp Schlüsselbund welcher die öffentlichen Schlüssel der Arbeitsgruppen enthält , mit denen die Ausführungsrechte überprüft werden.

Letztlich gibt es noch das lua Verzeichnis, welches die Lua Skripte und noch jede Menge anderes Zeug enthält:

.
+-- car1_my99_r
¦   +-- mdx_pool_reference
¦   +-- car1_my99_carcheck.carcheck
¦   +-- car1_my99_sw_versions.lua
¦   +-- lua_reference
¦   +-- files.inc
¦   +-- makefile
¦   +-- presets.rtd
¦   +-- ABC.seccode
+-- car1_my99_s
¦   +-- ...
+-- car1_my99_t
¦   +-- ...
+-- car1_my99_w
¦   +-- ...
+-- carcheck.footer
+-- carcheck.header
+-- carcheck.xslt
+-- db
¦   +-- oem.oodb
¦   +-- VehInfo_Stylesheet.xsl
+-- generic.make
+-- Healthfiles
¦   +-- OOBD-xmlfile.xml
+-- lib_lua
¦   +-- ...
+-- lib_protocol
¦   +-- ...
+-- local.make
+-- local_template.make
+-- makefile

Innerhalb des lua Verzeichnisses wird alles komplettiert. All diese Dateien haben verschiedene Bedeutungen:

Die Bedeutung der Dateien und Verzeichnisse

car1_my99_r /_t / _s / _w

Diese Verzeichnisse enthalten die Fahrzeugreihe und Modelljahr spezifischen Inhalte. Aber auch jedes Verzeichnis repräsentiert eine so genannte Arbeitsgruppe, welche benutzt wird wenn du die verschlüsselten Skripte benutzen möchtest. Wenn Du das tust, ermöglichst du den Nutzerzugriff für jede Arbeitsgruppe einzelnd, das bedeutet Du erlaubst den Nutzer das zu nutzen was Du in diesem Verzeichnis übersetzt.

Um eine klare Trennung zwischen den verschiedenen Niveaus der Risiken, was ein Benutzer mit Hilfe eines Skripts falsch machen kann zu etablieren, verwenden wir die Verzeichnisnamen um Erweiterungen zu definieren, in welchem ​​Verzeichnis ein Skript gespeichert werden muss. Dies geschieht um Missbrauch zu vermeiden. Die Erweiterungen sind ihre Bedeutung sind:

Erweiterung Bedeutung
_r Nur lesenden Zugriff - Kein Risiko einer nicht sachgemäßen Benutzung (sollte als Grundeinstellung für jeden nicht erfahrenen Erstnutzer erlaubt werden)
_t Zeitlich begrenzte Veränderungen - wie z.B. das Aktivieren von Ausgaben, die aber wieder in den Grundzustand versetzt werden, wenn die Diagnosesession endet. Geringes Risiko durch z.B Bewegen von Scheibenwischern (Ratschlag für Nutzer)
_s Service - Zum Starten von Testsequenzen, ändern von z.B dem Faktorymode des Fahrzeugs oder anderes (für Servicepersonal und andere Personen, die sich im Reparaturbereich eines Automobilbauers befinden)
_w Schreibenden Zugriff: Volle Kontrolle über das System Auto (nur für erfahrene Spezialisten)

mdx_pool_referenz

Wann immer Du eine Modulspezifikation aus dem Modulpool für diese bestimmte Fahrzeugbaureihe und Zugriffsebene kompilieren möchtest, listest Du den Namen der betroffenen Moduldateien in dieser mdx_pool_reference- Datei. Mit dieser Referenz, muß die Modulspezifikation nur in dem Pool-Verzeichnis gespeichert werden und es kann von verschiedenen anderen Orten darauf verwiesen werden.

car1_my99_carcheck.carcheck

Wann immer der Bauprozess ein *.carcheck Skript findet, nimmt es eine Liste von Modulen von dieser Fahrzeugbaureihe aus der mdx_pool_referenz und baut daraus eine Art von Summationskript auf, welches alle Module in sich aufnimmt und damit einen schnellen Überblick über das komplette Fahrzeug ermöglicht. Durch das Hinzufügen von Inhalt in dieses *.carcheck Skript, können ein paar Fahrzeugbaureihenspezifische Ausgaben zu dem generischen Inhalt der Fahrzeugauflistung hinzugefügt werden. “Inhalt”

car1_my99_sw_versions.lua

Im Gegensatz zu all den anderen automatisch erzeugten Ausgaben ist dies ein rein manuell hergestelltes Skript. Wenn der Bauprozess ein *.lua Skript findet, übersetzt er es.

lua_referenz

In Verbindung mit den “seccode” Dateien (siehe weiter unten) kannst Du das gleiche Skript für verschiedene Sicherheitsebenen übersetzen. Mit der lua_referenz Datei kannst Du das Original Skript in einem anderen Verzeichnis, auf es referenzieren und es in dem aktuellen Verzeichnis mit einem anderen Sicherheitlevel zu übersetzen.

Durch ein Abkommen muss das originale Skript in einem Arbeitsgruppenverzeichnis mit seinem geringsten Sicherheitslevel abgelegt werden und der höhere Sicherheitslevel muss darauf referenzieren.

ABC.seccode

*.seccode Dateien enthalten einen Teil des Lua Kodes, welcher den Sicherheitszugriffskode der Module definiert. In den Luaskripten selbst kann dann das Pseudo Kommando – optinclude(“ABC.seccode”), in denen der seccode nur enthalten ist wenn das Skript existiert. Es erzeugt aber keine Fehlernachricht wenn das Skript nicht existiert.

Aus Geheimhaltungsgründen sind diese *.seccode Dateien in dem Softwarerepository nicht eingebunden. Es ist ausserdem verboten diese oder andere Formate von Sicherheitskodes in das Repository hochzuladen. Deshalb hat jeder Entwickler sein Wissen über über Sicherheitskodes lokal für sich zu behalten und darf es nicht im Repository publizieren.

files.inc

Jede andere Datei, welche später vom Skript benötigt wird und welche nun nicht Teil des Übersetzungsprozess ist, wie z.B. DTC Datenbasen, kann in files.inc aufgelistet werden. Dadurch wird sie verschlüsselt und auch in das Ausgabeverzeichnis kopiert.

makefile

Dieses Makefile muss nicht editiert werden. Es wird nur für den Bauprozess benötigt.

presets.rtd

für spätere Erweiterungen.

carcheck.footer, carcheck.header und carcheck.xslt

Diese sind Vorlagen für die carcheck Skripte

db

Die hierin enthaltene Datenbasendateien (*.oodb) werden gespeichert um zu files.inc zu referenzieren, aber auch das stylesheet (VehInfo_Stylesheet.xsl) für einen Vehicle Health Report wird hier gespeichert.

generic.make

Diese Datei kontrolliert den gesammten Bauprozess und darf aus sehr guten Gründen nicht verändert werden…

Healthfiles

Wenn ein Fahrzeugreport erstellt wird durch die Benutzung des Skripts Carcheck, sollten die dabei entstandenen XML Dateien hier gespeichert werden. Wenn diese Datei in einem Webbrouser geöffnet wird, zeigt diese automatisch auf VehInfo_Stylesheet.xsl in dem db Verzeichnis und präsentiert die Daten mit dem richtigen Stylesheet.

lib_lua

In dieser findest du einige Lua Bibliotheksskripte für generische Funktionen

lib_protocol

In dieser hier findest du einige Lua Bibliotheksskripte für diagnosebezogene Funktionen

local.make und local_template.make

local.make enthält deine persönlichen Einstellungen. Es ist nicht Teil des Repositorys, weil es für jeden Benutzer unterschiedlich ist. Um die eigenen Einstellungen zu erzeugen, kopiere die Templatedatei lokal template.make und mache deine Einstellungen in local.make

cp local_template.make local.make

Makefile

Auch in dem lua Basisverzeichnis wird das Makefile für den Bauprozess benötigt. Ändere es einfach nicht.

Durchlauf des Makeprozesses

Im Gegensatz zu dem komplizierten Setup und den obigen Erklärungen, ist der eigentliche Bauprozess sehr einfach:

Bearbeite oder füge Dateien hinzu wie Du es benötigst. Für einen guten Start, wähle eins der existierenden *.lua Dateien, kopiere es wohin du es benötigst und gib Ihm einen eindeutigen Namen. Stelle sicher das die Fähigkeiten des Skriptes nicht die Sicherheitsrechte des Arbeitsgruppenordners überschreiten in dem es abgelegt ist.

Then type in the cygwin command line windows the following commands one after the other. If you do this in a workgroup folder, only the files in that folder will be proceed. If you type the commands in the lua root folder, then all workgroup folders, which you have listed in the local.make will be proccessed.

  1. make clean: this will remove all older results and temporary files
  2. make: This will convert all module XML files, all other templates and all *.lua files into Lua source files with the extension .luasource. Although normal *.lua files will only been copied by this, this renaming is necessary to not accidently delete some handwritten *.lua files when calling “make clean”
  3. make scripts: This will now start the real compile process, where the lua- compiler takes all luasource files and translates them into precompiled binaries (*.lbc). Hint: During the compilation of a script all include files are linked together in a temporary file called lua.tmp. If the compiler fails with any error message, that is the right file to look into why the compiler is complaining.
  4. make pack: When enabled and configured in local.make, this call will take all compiled *.lbc files and encrypt them accourding to the workgroup directory in which they are in, make up the folderstructure in the target directory, which is also configured in local.make, and and copy the results into it.

After that the final output can be found in the configured target directory, encrypted and ready to distribute.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
de/doc/lua_make.1418160648.txt.gz · Last modified: 2014/12/09 22:30 by wsauer