Komplettierung und diverse Korrekturen
git-svn-id: svn://svn.compuextreme.de/Viitor/V962/ViitorMake@5897 504e572c-2e33-0410-9681-be2bf7408885
This commit is contained in:
parent
a3205eeaeb
commit
d2b4248c0b
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user