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. *.seccode files contains a piece of lua code, which defines the security access codes of modules. In the lua scripts of the module itself you then can use the pseudo command – optinclude(“ABC.seccode”), which include the seccodes only if that file exist, but does not generate an error message if the file does not exist.

For confidential reasons, these *.seccode files are not included in the software repository, and it is forbitten to upload this or any other format of security codes into the repository, so each script developer has to maintain his personal knowledge about security codes locally and must not publish this into the repository.

files.inc

Any other file, which is needed by the script later and which is not already part of the lua compilation process, like e.g. DTC databases can be listed in the files.inc. By that it will be encrypted and copied to the output dir too.

makefile

This makefile don't need to be edited. It's just needed for the build process.

presets.rtd

for futher extensions.

carcheck.footer, carcheck.header and carcheck.xslt

These are the templates for the carcheck scripts

db

In here database files (*.oodb) are stored to reference to by files.inc, but also the stylesheet (VehInfo_Stylesheet.xsl) for a Vehicle Health report is stored here.

generic.make

This file controls the whole build process and must not be modified without very good reasons…

Healthfiles

When generating a vehicle report when doing a carcheck, the resulting XML files should saved here. When then opening the file in a web browser, the file automatically points to the VehInfo_Stylesheet.xsl in the db folder and present the data with the right style sheet.

lib_lua

In here you can find some lua library scripts for generic functions

lib_protocol

In here you can find some lua library scripts for diagnostic related functions

local.make and local_template.make

local.make will contain your personal settings. It is not part of the repository content, as it's content is different for each user. To generate your own local settings, copy the template file local_template.make and make your settings in local.make

cp local_template.make local.make

makefile

Also here in the lua base directory the makefile is needed for the build process. Just don't change it.

Running the make process

In opposite to all the complicate setup and explanations above, the build process is just simple:

Edit or add the files as you need. For a good start, choose one of the existing *.lua files, copy it to where you need it and give it a clear name. Make sure that the script capabilities do not exceed the security rights of the workgroup folder they are stored in.

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.1415045811.txt.gz · Last modified: 2014/11/03 21:16 by wsauer