Configure Make Make install

[Sven Broeckling]

Hallo!

> > Was ich da noch nicht ganz verstanden habe : wie laeuft das eigentlich
> > bei dem make install mit den Verschiedenen Distris. SuSE hat doch z.B.
> > KDE imo recht weit vom fhs entfernt liegen. Wenn ich nun z.B. bei einer
> > SuSE nach dem Kompilieren von KDE make install sage, baut der die
> > Binaries
> > dann so ein, wies in dem Makefile steht? Ich bin leider nie dazu
> > gekommen,
> > make und Makefiles mal naeher unter die Lupe zu nehmen...
> > Der Source ist nach dem make install doch eigentlich in jedem Fall
> > ueberfluessig, oder?
> dir Sourcen kann man dezent nach /dev/null verschieben. ./configure
> versteht immer(!) als wichtigsten Parameter
> --prefix=<Zielverzeichnis-Baum>
> d.h. da drunter wird alles eingehängt. Meistens ist das /usr/local
> dann werden die bins nach /usr/local/bin, die libs nach /usr/local/lib
> .... installiert man könnte sogar --prefix=/ sagen und dann wird alles
> in den Hauptbaum gepackt. Aber man kann das fast immer mit weiteren
> Parametern wie z.B. --prefix=/usr/local --bindir=/usr/bin ....
> deutlich genauer einpacken. 
Achso laeuft das. Naja, es stimmt schon, wer lesen kann ist klar im
Vorteil. Steht mit Sicherheit auch in fast allen READMEs und INSTALLs
drin...
Das war naemlich eine Sache, die mich immer etwas verunsichert hat.
Das /usr/src Verzeichnis und das Loeschen von Quellen etc.
Also ist eigentlich folgende Vorgehensweise ok

# pwd
/home/user
# tar xfvz irgend-eine-software-src.1.2.3.4.tgz
# cd irgend-eine-software-src.1.2.3.4
# ./configure
# make
# su -
Password : 
# make install
# exit
# cd ..
# rm -rf irgend-eine-software-src.1.2.3.4
# rm irgend-eine-software-src.1.2.3.4.tgz

> Eine andere Möglichkeit ist etwas komplizierter:
> Man legt jedes(!) Produkt in seine eigenes Verzeichnis /z.B. unter /opt)
> dann gibt es folgende Struktur:
> /opt/<Produktname>/<Versionsnummer>/src
> und in src die Quellen auspacken und dann mit
> ./configure --prefix=/opt/<Produktname>/<Versionsnummer> kompilieren und
> installieren. Dann kann man sogar (bei genug Plattenplatz) Mehrere
> Version
> parallel aufbewahren. Der einzige Nachteil ist, daß man sich jetzt noch
> einmalig(!) ein Skript bauen muß, das die ganzen Dateien die man braucht
> noch als symlinks(!) ins System integriert (und mit dem man sie dann
> auch
> wieder loswird). Oder man verlinkt die Teile alle einzeln...
Das ist bei einigen Sachen wirklich gut, vor allem wenn man unstable
Versionen testen will. Dann werd ich vielleicht doch heute nochmal
Gimp installieren (stable und die neueste). Im Moment hab ich naemlich
gar keins laufen.

> Ich praktizier das Spielchen nahezu jeden Tag, wobei ich dabei
> auch noch mehrere Architekturen und Versionen gleichzeitig (das geht
> wenn die Produkte sich selbst Versionieren könne: wie vim
> /usr/local/lib/vim/vim57 oder perl) sonst geht das nicht. Bei einfachen
> Binaries hängt man dann an das bin die Nummer drin, falls man mal ein
> altes
> benötigt und läßt den "standard"-Link auf dem neuesten.
> Bspl.:
> ln -s /opt/php3/3.0.15/bin/php /usr/local/bin/php3
> ln -s /opt/php4/4.0.1p2/bin/php /usr/local/bin/php4
> ln -s /opt/php4/4.0.1p2/bin/php /usr/local/bin/php
...praktisch genauso wie mit den Libs, nur das man eben noch den 
Link auf die aktuelle Setzt.

Vielen Dank
  Dem Durchblick wieder ein bisserl naeher
    Sven

-
Hinweise zur Benutzung dieser (und anderer Mailing-Listen) bitte beachten:
--> http://lug-owl.de/mailinglist_hints.html <--