Hallo, On Tue, 04 Feb 2003, Christian Boltz wrote:
Am Montag, 3. Februar 2003 21:23 schrieb David Haller:
On Mon, 03 Feb 2003, Christian Boltz wrote: [..]
Das wäre ja alles OK, wenn nicht auch ein Perl-Modul installiert werden müsste. Dessen Makefile wird mittels ExtUtils::MakeMaker und Makefile.PL generiert. Dummerweise beachtet das generierte Makefile PREFIX=. Gibt man also bei "make install" PREFIX=... an, wird das Perlmodul irgendwohin installiert (z. B. /usr/local/lib/perl/...), wo es Perl niemals findet :-|
Ueblich ist 'prefix' und _nicht_ PREFIX (z.B. bei autoconf generierten Makefiles), was das Problem loesen wuerde ;)
Ah ja. So fit bin ich mit Makefiles nicht, sind meine ersten ;-) (die erste Version dieser Makefiles stammt übrigens von Gerald Goebel)
*g*. Ich merk grad, mein Vorschlag war nicht ganz eindeutig... Also verwendet das "ueblichere" 'prefix' in den normalen Makefiles, dann stoert auch das 'PREFIX' im MakeMaker-Makefile nicht ;) Kann man ja mittels 'perl -p -i '~' -e 's/PREFIX/\L$&/g' oder so machen...
Ich wuerde uebrigens vorschlagen, dass ihr da eh noch was aendert:
prefix := /usr/local bindir := ${prefix}/bin
Klar.
BTW: Wieso verwendest Du :=
Siehe info make. Der Unterschied zwischen '=' und ':=' ist wann die Zuweisung expandiert wird. Gibt man einen "festen" string an, ist's eigentlich egal (aber s.u.), enthaelt der string aber etwas, das expandiert wird, dann wird mit ':=' genau einmal, naemlich dann, wenn die Zeile des Makefiles evaluiert wird expandiert, mit '=' wird nur ein "Makro" angelegt. Nehmen wir einfach mal folgendes: PWD = $(shell pwd) Jedes mal, wenn du nun $(PWD) irgendwo in einer Regel oder einer anderen Variablen (die gerade expandiert wird) verwendest wird nun 'pwd' aufgerufen. Mit PWD := $(shell pwd) wird pwd genau einmal aufgerufen, naemlich dann, wenn make der Variablen PWD den Wert zuweist. Anders gesagt: Verwendest du 'PWD = $(shell pwd)', dann enthaelt PWD '$(shell pwd)', und wenn du $(PWD) verwendest, ist das als wuerdest du selber $(shell pwd) an dieser Stelle schreiben. Verwendest du 'PWD := $(shell pwd)', dann enthaelt PWD das _ERGEBNIS_ der Expandierung, also das aktuelle Verzeichnis, und wenn du nun $(PWD) verwendest, ist das als wuerdest du selber das aktuelle Verzeichnis hinschreiben. Ich habe es mir zur Angewohnheit gemacht, dass ich moeglichst _immer_ ':=' verwende, es sei denn, ich will explizit, dass das zuzuweisende jedesmal ausgewertet wird...
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht. Und bin grad auch zu faul nachzuschauen. Das hab ich schlicht aus den autoconf-Makefiles... ;)
Meinen bescheidenen Makefile-Kenntnissen zufolge werden die Variablen mit $(...) geklammert und mit einem einfachen = zugewiesen.
s.o.
datadir := ${prefix}/share
OK, hab ich ja in HTMLPATH verwurstelt. Aber Deine Variante ist auch nicht verkehrt, da kann man ja immer noch
htmldir = $(datadir)/fontlinge/webgui
einbauen.
Genau. z.B. :)
docdir := ${datadir}/doc/fontlinge
Hmm. docdir oder docpath?
docpath. 'docdir' passt halt besser zu den anderen "ueblichen" Variablen.
BTW: Da hab ich absichtlich $prefix missachtet, weil ich Doku im "zentralen Dokumentationsverzeichnis" /usr/share/doc erwarte und nicht in /usr/local ;-) (ist vielleicht nur meine Meinung, aber ich schätze mal, dass viele Leute nicht unter /usr/local/share/doc suchen würden)
Nein. Ich hasse das! Wenn ich 'prefix=/foo' verwende, dann will ich _alles_ unterhalb von '/foo' -- es sei denn, ich spezifiziere explizit etwas anderes, z.B. fuer 'sysconfdir'. Und uebrigens: ich hatte mal ne Weile /usr/local/doc/ nach /usr/doc/ verlinkt, und das war "gar nicht gut"[tm]. Inzwischen hab ich's weitgehend wieder auseinandergepriemelt... Denk nur mal an den Fall, dass die "docdirs" nicht versioniert sind, wie bei SuSE ueblich, und dann installiere mal 2 Versionen einer lib... Wenn die eine in /usr [/share/doc] landet und die andere in /usr/local [/share/doc], dann ist alles ok, wenn nicht... IMNSHO muss '${datadir}/doc' der default sein. Nein, auch nicht '${datadir}/doc/packages'...
configdir := $(HOME)/.fontlinge
s/configdir/configfile/ ;-)
Ah. Flasch getippt :)
# HTMLPATH := $(HOME)/public_html/fontlinge # ^^^^^^^^^^^ Das gibt's bei mir nicht! Das # heisst bei mir 'wwwhome/htdocs'!
Hmm, liegt wohl an Deiner alten SuSE ;-)
Nein. Das liegt daran, dass ich die Doku von mod_userdir gelesen habe und ~/public_html nicht mochte, auch wenn's der default ist und war.
Seit ich Linux nutze (SuSE 7.0), liegt das Ganze unter ~/public_html.
Das ist _NUR_ der default! Wenn du willst kannst du UserDir auf /dev/zero setzen...
# Besser z.B. (ist aber auch nicht ideal!) htmldir := $(shell awk '/^[^#]*UserDir/{t=$2;sub("^.*\\*","$(HOME)",t);print t;}' /etc/httpd/httpd.conf)
Geht bei (neueren?) SuSE-Distris schief, weil das Ganze in separate Dateien ausgelagert ist :-|
cb@tux:~> grep "^[^#]*serDir" /etc/httpd/httpd.conf cb@tux:~> grep "^[^#]*serDir" /etc/httpd/* /etc/httpd/suse_public_html.conf: UserDir public_html cb@tux:~>
Stimmt. Zumindest aber die UserDir Direktive auszulagern, halte ich allerdings fuer, aehm, Unfug. Ich faende sowas sinnvoll: ==== LoadModule userdir_module /usr/lib/apache/mod_userdir.so AddModule mod_userdir.c UserDir public_html Include suse_public_html.conf ====
Außerdem heißt das Konfigurationsverzeichnis für den neuen Apache2 AFAIK /etc/apache2...
Dann schreibt man halt ein kl. scripterl, dass die Moeglichkeiten durchtestet [und z.B. dem User als default vorschlaegt]...
Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet...
Könnte schwierig werden, siehe oben ;-)
Och, nicht wirklich ;)
Achja, dann muesste man auch die scripte wohl noch anpassen (hart kodierte Pfade *tsk*),
Naja, es funktioniert aber trotzdem (und kann auch durch xy=/hier/hin überschrieben werden)
Ich hab's noch nicht getestet, ich bin mir aber recht sicher, dass es bei mir nicht funktionieren wuerde... [..]
PS: Da wir gerade dabei sind, gleich noch eine Frage: make install verhält sich unterschiedlich, je nachdem, ob es als root oder als User aufgerufen wird [1] (wird über `whoami` getestet). Gibt es da irgendwelche Bedenken oder bessere Möglichkeiten?
Wie waer's mit nem test auf die UID? ABER: s.u.! Oder vielleicht besser, ein kl. install-script[3], dass einen Parameter '-net' oder sonstwas kennt, um zwischen 'system'- und 'user'-Installation zu unterscheiden... Koennte ja sein, dass 'root' mal nicht ins "system" installieren will *eg*
[1] betrifft hauptsächlich die Installation des WebGUI: make install verhält sich dabei folgendermaßen: - als user installiert es nach ~/public_html/fontlinge und legt einen Symlink zur ~/.fontlinge an - als root installiert es nach $(PREFIX)/share/fontlinge/webgui und erzeugt das Script $(BIN)/fontlinge_userinstall [2]
Und wie wird im letzteren das share/fontlinge/webgui dann dem Indianer bekannt gemacht? Bei mir sitzt der in /usr/local/httpd/htdocs/... Und wozu der ganze Aufwand? Das laesst sich doch via prefix/configure regeln! ./configure --prefix='/home/dh' --htmlroot='${prefix}/wwwhome/htdocs' ./configure --prefix='/usr/local' --htmlroot='${prefix}/htdocs' ./configure --prefix='/opt/fontlinge' \ --htmlroot='/usr/local/httpd/htdocs/fontlinge' So ein configure ist nicht weiter schwer -- man kann ja abkupfern (v.a. das "option-handling" von nem autoconf configure-script)... Da koennte man sogar noch den default fuer 'htmlroot' von der prefix abhaengig machen. ==== pseudo-code ==== if test -z "$htmlroot"; then case "$prefix" in /usr) htmlroot="...";; /usr/local) htmlroot="...";; *home*) htmlroot="~/public_html";; # ... esac fi ==== Aber wie gesagt: ich versuche, mir das ganze mal genauer anzuschauen... -dnh [1,2] NMF [3] statt dem (obersten) Makefile, oder das dann 'make INSTTYPE=user' oder so aufruft -- Körperverletzung kann bei Sahne auch durch längeres schlagen nicht hervorgerufen werden. Und selbst wenn, das Beweismaterial lässt sich nachher durch Verzehr vernichten. [Woko° in dag°]