Hallo David, hallo Leute, Am Dienstag, 4. Februar 2003 23:49 schrieb David Haller:
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: [..] 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 ;)
OK.
datadir := ${prefix}/share
docdir := ${datadir}/doc/fontlinge
Hmm. docdir oder docpath?
docpath. 'docdir' passt halt besser zu den anderen "ueblichen" Variablen.
Dann also docpath (obwohl es nicht so gut zum Rest passt ;-)
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'.
Gut, überzeugt. Ich ändere es auf $(prefix)/share/doc/.
Und uebrigens: ich hatte mal ne Weile /usr/local/doc/ nach /usr/doc/ verlinkt, und das war "gar nicht gut"[tm].
Und ich überlege ernsthaft, genau dieses zu tun. Wenn ich nämlich nach Doku suche, "vergesse" ich meistens /usr/local/share/doc :-|
Inzwischen hab ich's weitgehend wieder auseinandergepriemelt...
Naja, bei mir liegt in /usr/local/doc/ (ohne /share/ dazwischen :-| nur eine einsame sane-Doku, weil mein Scanner nur mit gepatchtem Sane läuft. Klar, ich könnte auch das .spec vom SuSE-srpm nehmen, aber es läuft ja auch so (war IIRC eine checkinstall-Installation *flücht*)
IMNSHO muss '${datadir}/doc' der default sein. Nein, auch nicht '${datadir}/doc/packages'...
packages/ hat mir Ratti schon verboten ;-) [~/public_html - oder doch wo anders?]
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.
Damit dürftest Du aber die große Ausnahme sein. Oder anders ausgedrückt: wer das ändert, weiß auch, wie er die Fontlinge WebGUI an die richtige Stelle installiert ;-) (derzeit: HTMLPATH=~/wwwhome/htdocs/fontlinge/) Außerdem glaube ich mich zu erinnern, dass ~/public_html in Teilen des Apache (suExec) fest einkompiliert ist und eine Änderung von daher recht aufwendig wird ;-)
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 ====
Naja, dann bräuchte man für den Rest auch nicht mehr großartig auszulagern... BTW: Ich habe mir eine /etc/httpd/httpd.vhosts erstellt, da ich eben an den vhosts am meisten drehe (und am Rest der config fast nie) ;-)
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...
Was spricht dagegen?
[..]
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*
Gute Idee. Statt `whoami` stelle ich das Ganze also um auf install_type=system (bzw. user)
[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?
Gar nicht, das wird ja durch fontlinge_userinstall ins ~/public_html kopiert ;-) Liegt u. a. daran, dass auch ein (Symlink auf eine) .fontlinge dabeiliegen muss ;-)
Und wozu der ganze Aufwand? Das laesst sich doch via prefix/configure regeln!
Wie es aussieht, klappt es auch per make install prefix=.. htmlpath=.. Ist noch einfacher, da ich das nicht erst schreiben muss ;-)
./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)...
Klar, aber _kein_ configure-Script schreibt man schneller als _ein_ configure-Script *g*
Aber wie gesagt: ich versuche, mir das ganze mal genauer anzuschauen...
*freu*
[3] statt dem (obersten) Makefile, oder das dann 'make INSTTYPE=user' oder so aufruft
Gute Idee, s. o, wird übernommen :-)) Gruß Christian Boltz -- [Fontlinge] Glücklich wirst du damit nicht werden. Die Windowsversion konnte das, denn ich war jung und dumm, brauchte das Geld und dachte, man könne sich auf Standards verlassen. Die Sortierung nach PanoseID ergab dann das maximale Durcheinander. :-( [Ratti]