CompuExtreme/ViitorMake
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Komplettierung und diverse Korrekturen

Browse Source 
git-svn-id: svn://svn.compuextreme.de/Viitor/V962/ViitorMake@5897 504e572c-2e33-0410-9681-be2bf7408885
This commit is contained in:
kueller 2010-12-20 09:04:29 +00:00
parent a3205eeaeb
commit d2b4248c0b
1 changed files with 66 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

165
DOC/Module_Programming_Guide
View File

@ -1,4 +1,4 @@
ViitorLinux genpkg Module Programming Guide
ViitorLinux genpkg Module Programming Guide
Hier wird versucht einen Ueberblick ueber die Funktionalitaet von genpkg
zu geben, sowie die daraus resultierenden Richtlinien zur Module
@ -12,7 +12,8 @@ werden ueber Variablen die Pfade zu den Sourcen, zum "Make" Verzeichniss, in
welchem die Sourcen entpackt, und die binarys erzeugt werden, usw eingestellt.
Ausserdem wird die System Optimierung fuer das Zielsystem ($TARGET, $CPU)
eingestellt.
Dabei ist $TARGET von $CPU abhaengig. Aktuell werden folgende TARGET unterstuetzt:
Dabei ist $TARGET von $CPU abhaengig. Aktuell werden folgende
TARGET definitionen unterstuetzt:
i586-Viitor$VERSION-linux-gnu = Pentium,
K6 prozessoren
@ -25,8 +26,8 @@ athlon-Viitor$VERSION-linux-gnu = AMD Athlon K7,
x86_64-Viitor$VERSION-linux-gnu = AMD K8 (opteron),
amd64
turion als multilib (32/64 BIT)
ungetestet mangels system: Intel CPU mit EMT64
sparc64-Viitor$VERSION-linux-gnu = Ultrasparc2 CPU im Multilib Modus
Intel CPU mit EMT64
sparc64-Viitor$VERSION-linux-gnu = Ultrasparc2 (In Entwicklung)
Die Funktion der Pfad Variablen ist im File defsys hinreichend
dokumentiert. Daher wird hier nicht naeher darauf eingegangen.
@ -37,11 +38,11 @@ eine entsprechendes Verhalten festgelegt.
BIT1 (1):Wenn binaerpacket schon existiert, entsprechenden Warnhinweis
Unterdruecken
BIT2 (2):Package mit "forece" (-f bei installpkg) installieren.
BIT2 (2):Package mit "forec" (-f bei installpkg) installieren.
d.H. das package wird ohne rueckfrage, auch wenn es bereits
installiert ist eingespielt
BIT3 (4):Sources nicht entpacken. Modul kuemmert sich selber darum
Dies ist vor allem bei inconsistenten srcarchive- srcdir- und
Dies ist vor allem bei inkonsistenten srcarchive- srcdir- und
Modulenamen notwendig
BIT5 (8):pkg erzeugung wird unterbunden. Nach dem build muss
Sich das Modul selber darum kuemmern. Ist dann notwendig,
@ -55,6 +56,7 @@ BIT7 (32):dependics als "forced" ein *.dep eintragen. Damit wird eine
Installation ohne vorhandene dependics unterbunden.
BIT8 (64):Aufraeumen des source verzeichnisses nach dem Build unterlassen
BIT9 (128):Vorhandene Patches NICHT automatisch anwenden
BIT10 (256):installpkg mit -o (overwrite existing files) ausführen
Bits in einer Variablen koennen mit
@ -92,10 +94,9 @@ Der Ablauf von genpkg;
genpkg bekommt als Argument den Namen des zu verwendenden Modules uebergeben.
Ueber die Funktion (in functions/functions definiert) UnPack werden in
$LFSSOURCE/$SRCPATH gefundene source archive (tar.gz, tar.bz2) nach $MKPKG (aus
defsys) entpackt.
Weiterhin wird geprueft ob gleichnamige files mit <ARCHPATTERN>.patch.*
existieren.
$LFSSOURCE/$SRCPATH gefundene source archive (tar.gz, tar.bz2) nach
$MKPKG (aus defsys) entpackt. Weiterhin wird geprueft ob gleichnamige files
mit <ARCHPATTERN>.patch.* existieren.
Sofern diese vorhanden sind, und BIT9 (128) in $MKPKG NICHT gesetzt ist,
werden die patches mit "patch -p1" im gerade entpackten sourcetree eingespielt.
Weiterhin wird $TMPROOT um <PKGNAME> erweitert; TMPROOT=$TMPROOT/<pkgname>$$ und
@ -171,6 +172,7 @@ dev.tar
man.drg
man.cont
man.tar
preinstall
Dieses File wird nach $DISTTARGET/$SRCPATH geschrieben.
@ -204,6 +206,7 @@ init/ Ein hier vorgefundenes genpkg wird gesourced,
nach beendigung von init/genpkg geloescht!
CVS alle vorhandenen CVS Verzeichnisse werden
geloescht
.svn Subversion status files werden ebenfalls aufgeraeumt
Nach dieser Aufbereitung werden alle vorhandenen Verzeichnisse und files
1:1 nach $TMPROOT kopiert.
@ -250,9 +253,9 @@ ArchiveName() Wandelt den Namen eines beliebigen Source Archives in
ERGEBNISS=`ArchivName()`
ARGUMENTE: ArchiveName <src filename>
GetCVS() Dient dem Checkout von Addon File fuer pkgs. Ist weiter
GetSVN() Dient dem Checkout von Addon File fuer pkgs. Ist weiter
oben genauer beschrieben!
ARGUMENTE: GetCVS <CVS Projetct Name> <$TMPROOT>
ARGUMENTE: GetSVN <Subversion Projetct Name> <$TMPROOT>
GenDependics() Gibt eine Liste aller Librarys der im Uebergebenen Pfad
befindlichen binary Files zurueck
@ -262,6 +265,12 @@ StripPkg() Durchsucht den angegebenen Pfad nach binary files, und
entfernt unnoetige debugging informationen aus diesen.
ARGUMENTE StripPkg <Verzeichniss in welchem gesucht werden soll>
ClearHostSysNameing32()
Siehe ClearHostSysNameing. Hier geht es um TARGET32, wie
von mk32() verwendet. und ist beim Multilib Build fuer
die 32 Bit Version der Binarys
ARGUMENTE: ClearHostSysNameing <Zu untersuchendes Verzeichniss>
ClearHostSysNameing()
Wird beim ./configure aufruf eine --target oder --host
angegeben, nehmen manche makes dies zum anlass die erzeugten
@ -271,17 +280,6 @@ ClearHostSysNameing()
benennt diese nach <binname> um.
ARGUMENTE: ClearHostSysNameing <Zu untersuchendes Verzeichniss>
ClearHostSysNameing32()
Siehe ClearHostSysNameing. Hier geht es um TARGET32, wie
von mk32() verwendet. und ist beim Multilib Build fuer
die 32 Bit Version der Binarys
ARGUMENTE: ClearHostSysNameing <Zu untersuchendes Verzeichniss>
ClearTargetNameing()
Siehe ClearHostSysNameing. Jedoch wird hier nicht
Umbenannt, sondern ein link mit <binname> angelegt.
ARGUMENTE: ClearTargetNameing <zu untersuchendes Verzeichniss>
MakeCheck() Wrapper fuer "make check". Prueft ein FLAG, das z.B. bei
makeViitor mit der Option -c gesetzt wird, und fuehrt
nur wenn das FLAG gesetzt ist ein
@ -289,50 +287,7 @@ MakeCheck() Wrapper fuer "make check". Prueft ein FLAG, das z.B. bei
aus.
ARGUMENTE: MakeCheck <Optionen fuer make>
NoOpt() Schaltet die Optimierung (durch $CFLAGS und $CXXFLAGS)
fuer den aktuellen build in 2 stufen aus.
Hinfaellig ab der Viitor Version 961, da hier keine
CFLAGS mehr gesetzt werden, und die Optimierung im
Module explizit durch Verwendung von $BUILDOPTIONS und
$BUILDOPTIONS32 selektiert werden muss.
ARGUMENTE: NoOpt [0|1|2]
0 Optimierung off
2 Optimierung off
* Optimierung O3 entfernen alles andere
beibehalten
RestoreOpt() Schaltet die mit NoOpt ausgeschaltene Optimierung wieder
ein wird durch CleanUp() aufgerufen!
InstallOldKernelh()
Tauscht /usr/src/linux durch die Kernelheader eines
2.4.x kernels aus. Hilft oft bei kompile Problemen die
aus api aenderungen am aktuellen Kernel resultieren.
Muss fuer die V961 neu geschrieben werden, sofern sie
noch benoetigt wird.
ARGUMENTE: InstallOldKernelh [1]
1 Installieren
* Orginal Kernel wieder herstellen
Wird so von CleanUp aufgerufen.
UseOldGcc() Leider hat sich im laufe der gcc Entwicklung auch das
Verstaendniss der C Syntax im gcc angepasst.
Daraus resultiert, das der aktuelle gcc (V961 verwendet
den gcc 4.1.1) oft aeltere sourcen (ANSI C, oder gar
Kerningham Richi C) als fehler anmeckert.
Daher werden in Viitor verschiedene gcc Versionen
verwendet. die Aelteste Version stellt der gcc/2.95.x
dar, mit Viitor V961 nicht mehr erstellt wird, da diesem
eine Unterstuetzung fuer 64 Bit vollstaendig fehlt.
Ansonsten wird noch eine 3.3.x mitgeliefert, welche sich
als sehr zuverlaessig erwiesen hat.
Mittels dieser Funktion kann die zu verwendende gcc
version umgeschalten werden.
ARGUMENTE; UseOldGcc [1|2]
1 gcc-2.95-3 Verwenden
2 gcc-3 Verwenden
* System default gcc verwenden
Wird so von CleanUp verwendet.
CleanTextFiles entfernt aus allen files in $TMPROOT den string aus $TMPROOT
GetFlags() Rechnet Rechte strings wie sie von ls -l ausgegeben
werden in Ihre Oktalen Entsprechungen um und gibt den
@ -353,20 +308,21 @@ MakeMgtFiles() Erstellt aus einem vorgegebenen Tree die <prefix>.cont
SetConfig() $PKG_CONFIG_PATH steuert pkg-config. und gibt diesem an,
wo die files zur Linker Configuration von libraries zu
finden sind. Die Entsprechenden Konfigurationen werden von
den entsprechenden Libraries mitgebracht, und beim "make install"
eingespielt.
Mit Viitor64 liegen diese sowohl unter */lib/pkgconfig als auch
unter */lib64/pkgconfig. Je nachdem ob fuer 32 BIT oder fuer 64
BIT gebaut wird, muss nun das richtige configfile gewaehlt werden.
Welche verwendet werden bestimmen die pfade in $PKG_CONFIG_PATH.
SetConfig sorgt jetzt mittels sed dafuer, das entweder nur
die lib64 ("s/lib/lib64/") oder nur die lib ("s/lib64/lib")
verzeichnisse durchsucht werden.
finden sind. Die Entsprechenden Konfigurationen werden
von den entsprechenden Libraries mitgebracht, und beim
"make install" eingespielt.
Mit Viitor64 liegen diese sowohl unter */lib/pkgconfig
als auch unter */lib64/pkgconfig. Je nachdem ob fuer
32 BIT oder fuer 64 BIT gebaut wird, muss nun das
richtige configfile gewaehlt werden. Welche verwendet
werden bestimmen die pfade in $PKG_CONFIG_PATH.
SetConfig sorgt jetzt mittels sed dafuer, das entweder
nur die lib64 ("s/lib/lib64/") oder nur die lib
("s/lib64/lib") verzeichnisse durchsucht werden.
ARGUMENTE: SetConfig [32|64|0]
32 PKG_CONFIG_PATH auf lib umstellen
64 PKG_CONFIG_PATH auf lib64 umstellen
0 Orginal PKG_CONFIG_PATH wieder herstellen
32 PKG_CONFIG_PATH auf lib umstellen
64 PKG_CONFIG_PATH auf lib64 umstellen
0 Orginal PKG_CONFIG_PATH wieder herstellen
X11R7_Fix() Mit der Umstellung der X11 Version auf 7.x.x wird in
Viitor auch aus /usr/X11R6 ein /usr/X11R7. Einige
@ -376,26 +332,37 @@ X11R7_Fix() Mit der Umstellung der X11 Version auf 7.x.x wird in
koennen. Dies wird nach Erstellung des Packages von
CleanUp wieder entfernt
Fix_Input_h() Einige Programme, die Joysticks, maus oder tastatur
verwenden sind von den deklarationen in
/usr/src/linux/include/linux/input.s bzw.
/usr/include/linux/input.h abhaengig. Da in Kernel 2.6.x
permanent aenderungen der api stattfinden, macht dieses
file in aktuellen versionen haeufig probleme.
Mit dieser Routine wird eine "saubere" input.h aus dem
Kernel 2.4.x tree temporaer eingespielt, die nachher
durch CleanUp wieder aufgeraeumt wird.
MakeFifo() Legt einen Fifo an und gibt den Filenamen zurück.
wird von ExecCommand benötigt (paralles abarbeiten
von Shell Commands)
UseKernelh() Die mit V961 eingefuehrten gepatchten kernel Header files
von linuxfromscratch sind leider nicht komplett. Werden kernel
Includes benoetigt, die in den linuxfromscratch packeten nicht
enthalten sind, kann mit UserKenrelh 1 auf die unter
/usr/src/linux/include/linux installierten header umgeswitcht
werden. Cleanup, oder ein UserKernelh 0 switcht wieder auf
die gepatchten includes zurueck.
ARGUMENTE: UseKernelh [1|0]
1 = auf /usr/src/linux/include/linux switchen
0 = /usr/include/linux.orig wieder herstellen
ExecCommand() Führt commandos nach einem InitDirspatch parallelisiert
aus.
InitDispatch() Initialisiere Pralell Shell Execution Environment
DispatchCmd() Auführungsroutine für Prallel Execution Environment
EndDispatch() Wartet daruaf das Alle Commands im Parallel Excution
Environment sich beenden, und beendet dann das PEE.
GenDynLib32() Baut aus einer statischen Library entsprechende
Dynamische Pendantes. Hierzu ist es notwendig das die
Objectfiles der statischen Library mit -fPIC übersetzt
wurden. Als Argumente muss der Absolute (!) Pfad zur
Statischen Library, sowie die Version der zu
erzeugenden Dynamischen Library angegeben werden.
Diese Funktion muss speziell bei einem Multilib (64Bit)
build verwendet werden, wenn eine 32 Bit Library
gebaut werden soll (aus eine 32 Bit Statischen Lib)
GenDynLib() Siehe GenDynLib32(). Baut 64 Bit Libs bei einem
Multilib Build, und 32 Bit libs bei einerm 32 Bit Build
extractfile() Extrahiert Files aus einem Viitor Archive.
Aufruf mit: extractfile <ArchiveName> <FileName>
wobei Filename der name eines Archive Bestandteils sein
muss (wie weiter oben beschrieben)
Wird bei der Modulerstellung bemerkt, das weitere Routinen sinnvoll
sind, so koennen diese in functions/functions erstellt werden, und