diverse Makefiles, Makefile.PL und PREFIX
Hallo Leute, ich bastle seit einiger Zeit bei Rattis Fontlingen mit. Klappt soweit, es gibt auch "in Kürze"[TM] ein "stable release", aber vorher noch rund 1 Woche Betaphase. (Betatester gesucht!) Leider bin ich beim Testen der Makefiles auf ein Problem gestoßen. Die Fontlinge verwenden einige Makefiles, die per make -C verzeichnis install eingebunden werden. 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 :-| Zwischenzeitlich lasse ich in dem von Makefile.PL generierten Makefile PREFIX durch PERLPREFIX zu ersetzen. Da aber das generierte Makefile recht groß und daher wenig übersichtlich ist, weiß ich nicht, ob diese Methode das Gelbe vom Ei ist. Insbesondere stört mich, dass PREFIX= nochmal in der Variable PASTHRU aufgenommen wird, und das wird bei make disttest (was macht das eigentlich?) verwendet. Oder macht das gar nix und disttest ist nur ein "überflüssiges" Target [1] im Makefile? Gruß Christian Boltz [1] verwendet wird eigentlich nur: - make - make test - make install - make clean und eben die davon abhängigen Targets, bei denen ich noch nicht so recht durchblicke [2] [2] Gibt es ein Programm, das mir das Makefile übersichtlich, z. B. in Baumstruktur darstellt, und das noch mit frei wählbarem Startpunkt, z. B. install)? -- Fontlinge: font management for Linux ### BETATESTER GESUCHT! ### Infos und Download: http://www.gesindel.de
Hallo, On Mon, 03 Feb 2003, Christian Boltz wrote:
Leider bin ich beim Testen der Makefiles auf ein Problem gestoßen.
Die Fontlinge verwenden einige Makefiles, die per make -C verzeichnis install eingebunden werden.
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 ;)
Zwischenzeitlich lasse ich in dem von Makefile.PL generierten Makefile PREFIX durch PERLPREFIX zu ersetzen.
Auch ne Variante. Ich wuerde uebrigens vorschlagen, dass ihr da eh noch was aendert: prefix := /usr/local bindir := ${prefix}/bin datadir := ${prefix}/share docdir := ${datadir}/doc/fontlinge configdir := $(HOME)/.fontlinge # HTMLPATH := $(HOME)/public_html/fontlinge # ^^^^^^^^^^^ Das gibt's bei mir nicht! Das # heisst bei mir 'wwwhome/htdocs'! # Besser z.B. (ist aber auch nicht ideal!) htmldir := $(shell awk '/^[^#]*UserDir/{t=$2;sub("^.*\\*","$(HOME)",t);print t;}' /etc/httpd/httpd.conf) Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet... Achja, dann muesste man auch die scripte wohl noch anpassen (hart kodierte Pfade *tsk*), da koennte man z.B. ein sed-script wie beim configure (foo.in -> foo) drueberjagen... Evtl. kann man das ganze aber sogar im Makefile.PL machen... Ich schau mir die fontlinge mal an, wenn ich kann ;) -dnh, der nur mal eben einen Blick in den tarball geworfen hat -- SPECIAL OFFER! I proofread unsolicited commercial email sent to this address at a rate of US$ 500.00 per incident! Include billing address in your message and save US$ 100.00 per hour off ordinary address resolution and tracking charge!
Hallo David, hallo Leute, Am Montag, 3. Februar 2003 21:23 schrieb David Haller:
On Mon, 03 Feb 2003, Christian Boltz wrote:
Die Fontlinge verwenden einige Makefiles, die per make -C verzeichnis install eingebunden werden.
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)
Ich wuerde uebrigens vorschlagen, dass ihr da eh noch was aendert:
prefix := /usr/local bindir := ${prefix}/bin
Klar. BTW: Wieso verwendest Du := und geschweifte Klammern um die Variablennamen? Meinen bescheidenen Makefile-Kenntnissen zufolge werden die Variablen mit $(...) geklammert und mit einem einfachen = zugewiesen.
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.
docdir := ${datadir}/doc/fontlinge
Hmm. docdir oder docpath? 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)
configdir := $(HOME)/.fontlinge
s/configdir/configfile/ ;-)
# HTMLPATH := $(HOME)/public_html/fontlinge # ^^^^^^^^^^^ Das gibt's bei mir nicht! Das # heisst bei mir 'wwwhome/htdocs'!
Hmm, liegt wohl an Deiner alten SuSE ;-) Seit ich Linux nutze (SuSE 7.0), liegt das Ganze unter ~/public_html. Ratti nutzt ja seit kurzem Debian und hat auch noch nix davon gesagt, dass es woanders liegt.
# 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:~> Außerdem heißt das Konfigurationsverzeichnis für den neuen Apache2 AFAIK /etc/apache2...
Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet...
Könnte schwierig werden, siehe oben ;-)
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)
da koennte man z.B. ein sed-script wie beim configure (foo.in -> foo) drueberjagen...
Evtl. kann man das ganze aber sogar im Makefile.PL machen...
Vorschläge sind stets willkommen ;-)
Ich schau mir die fontlinge mal an, wenn ich kann ;)
Schön. Vorschläge, Unverständliches in der Doku (Stichwort "Betriebsblindheit" ;-) und Bugreports kannst Du (und jeder andere auch) gern schicken. Egal ob hier, auf fontlinge-devel oder direkt an Ratti oder mich ;-)
-dnh, der nur mal eben einen Blick in den tarball geworfen hat
;-) Gruß Christian Boltz 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? [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] [2] $(BIN)/fontlinge_userinstall enthält dann den Befehl make -C /usr/local/share/fontlinge/webgui "$@" install (es wird das gleiche Makefile wie bei [1] verwendet) --
[suse-linux Statistik] Hm. Apropos: Was meint ihr, sollte ich 'ratti / Joerg' zusammenfassen? Ja, oder? Ich denke ja schon, aber Ratti ist dagegen. [> David Haller und Jörg Roßdeutscher aka Ratti in sl-etikette]
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°]
Am Die, 2003-02-04 um 23.49 schrieb David Haller:
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:
Ich habe es mir zur Angewohnheit gemacht, dass ich moeglichst _immer_ ':=' verwende, es sei denn, ich will explizit, dass das zuzuweisende jedesmal ausgewertet wird... Keine gute Idee. ':=' ist nicht portabel, weshalb es von Automake auch nicht verwendet wird.
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht.
$() .. Makefile-Variablen. ${} .. Shell/Environment-Variablen. Manche "make"s unterscheiden da sehr streng, andere makes sind da etwas "lässiger" (GNU-make gehört "leider" dazu). Das kann zu "netten" Überraschungen führen, wenn man versucht mit gnu-make geschriebene, vorgeblich portable Makefiles auf anderen U*ixen zu verwenden.
Und bin grad auch zu faul nachzuschauen. Das hab ich schlicht aus den autoconf-Makefiles... ;) Automake-Makefiles, autoconf-Makefile's gibt es nicht ;)
Automake verwendet für make-Variablen nur runde Klammern und '='.
Meinen bescheidenen Makefile-Kenntnissen zufolge werden die Variablen mit $(...) geklammert und mit einem einfachen = zugewiesen. So ist es.
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. Für docdir? Wäre eine sinnvolle Möglichkeit. $(docdir) wird von den GNU-Standards nicht erfasst, ist somit frei wählbar. Was im Endeffekt wirklich sinnvoll ist, hängt vom Sinn und Zweck dieser Files ab.
Außerdem heißt das Konfigurationsverzeichnis für den neuen Apache2 AFAIK /etc/apache2... Nein, ist installationsabhängig bzw. Vendor-spezifisch, d.h. es kann buchstäblich irgendwo liegen
(RH z.B. verwendet /etc/httpd mit /etc/httpd/conf/httpd.conf und Modulkonfigurationen in /etc/httpd/conf.d/*.conf).
Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet...
Ich würde hier schlicht und einfach eine configure-Option einführen (--with-httpd=<path> o.ä.) und dann den Pfad und die darin enthaltenen Dateien auf Verwendbarkeit für eure Zwecke testen.
Könnte schwierig werden, siehe oben ;-)
Och, nicht wirklich ;) Doch, das kann lustig werden ;)
Schau dir mal die Tricks an mit denen autoconf's AC_PATH_PROG und Co. arbeiten. [Wie meinte doch neulich ein OS/2 oder CygWin-User: PATH=C:\backspace\return;E:\tab\newline;D:\home W:\pakete\mypaket\configure --prefix=F:\fondlinge Oder auch: PATH="${HOME}/Oktoberfest 2003:$PATH" configure '--prefix=Auf geht\'s' ]
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). Just don't!
Gibt es da irgendwelche Bedenken oder bessere Möglichkeiten? Es gäbe viele Möglichkeiten, aber die von Euch scheinbar gewählte ist so ziemlich die Schlechteste (Sorry)
Ein paar Alternativen: 1. Nur systemweite Installation vorsehen und darin ein User-Install-Script einbauen, das eine user-spezifische Installation einrichtet. 2. Keinen Unterschied zwischen user- und systemweiter Installation machen, es dem User überlassen, wie er seine userspezifische Installation einrichtet (mittel entsprechender Konfigurationsoptionen) Ralf
Hallo, On Wed, 05 Feb 2003, Ralf Corsepius wrote:
Am Die, 2003-02-04 um 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:
Ich habe es mir zur Angewohnheit gemacht, dass ich moeglichst _immer_ ':=' verwende, es sei denn, ich will explizit, dass das zuzuweisende jedesmal ausgewertet wird... Keine gute Idee. ':=' ist nicht portabel, weshalb es von Automake auch nicht verwendet wird.
Ah. OK.
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht.
$() .. Makefile-Variablen. ${} .. Shell/Environment-Variablen.
Manche "make"s unterscheiden da sehr streng, andere makes sind da etwas "lässiger" (GNU-make gehört "leider" dazu). Das kann zu "netten" Überraschungen führen, wenn man versucht mit gnu-make geschriebene, vorgeblich portable Makefiles auf anderen U*ixen zu verwenden.
Und bin grad auch zu faul nachzuschauen.
Ah. Danke :)
Das hab ich schlicht aus den autoconf-Makefiles... ;) Automake-Makefiles, autoconf-Makefile's gibt es nicht ;)
Oh, stimmt. letzters jagt ja das .in durch...
Automake verwendet für make-Variablen nur runde Klammern und '='.
Meinen bescheidenen Makefile-Kenntnissen zufolge werden die Variablen mit $(...) geklammert und mit einem einfachen = zugewiesen. So ist es.
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. Für docdir?
Jep.
Wäre eine sinnvolle Möglichkeit. $(docdir) wird von den GNU-Standards nicht erfasst, ist somit frei wählbar. Was im Endeffekt wirklich sinnvoll ist, hängt vom Sinn und Zweck dieser Files ab.
*g* Hab also nicht nur Unfug geschrieben ;)
Außerdem heißt das Konfigurationsverzeichnis für den neuen Apache2 AFAIK /etc/apache2... Nein, ist installationsabhängig bzw. Vendor-spezifisch, d.h. es kann buchstäblich irgendwo liegen
(RH z.B. verwendet /etc/httpd mit /etc/httpd/conf/httpd.conf und Modulkonfigurationen in /etc/httpd/conf.d/*.conf).
Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet...
Ich würde hier schlicht und einfach eine configure-Option einführen (--with-httpd=<path> o.ä.) und dann den Pfad und die darin enthaltenen Dateien auf Verwendbarkeit für eure Zwecke testen.
Jup. Naja, ein paar defaults kann man ja anbieten (und falls nix gefunden wird abbrechen).
Könnte schwierig werden, siehe oben ;-)
Och, nicht wirklich ;) Doch, das kann lustig werden ;)
Apropos: Wie waere's mit: `apxs -q sysconfdir` als default? Das sollte doch eigentlich meist klappen...
Schau dir mal die Tricks an mit denen autoconf's AC_PATH_PROG und Co. arbeiten.
Wuest. Ja.
[Wie meinte doch neulich ein OS/2 oder CygWin-User: PATH=C:\backspace\return;E:\tab\newline;D:\home W:\pakete\mypaket\configure --prefix=F:\fondlinge
Oder auch:
PATH="${HOME}/Oktoberfest 2003:$PATH" configure '--prefix=Auf geht\'s' ]
Uhoh!
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). Just don't!
*hehe*
Gibt es da irgendwelche Bedenken oder bessere Möglichkeiten? Es gäbe viele Möglichkeiten, aber die von Euch scheinbar gewählte ist so ziemlich die Schlechteste (Sorry)
Ein paar Alternativen:
1. Nur systemweite Installation vorsehen und darin ein User-Install-Script einbauen, das eine user-spezifische Installation einrichtet.
2. Keinen Unterschied zwischen user- und systemweiter Installation machen, es dem User überlassen, wie er seine userspezifische Installation einrichtet (mittel entsprechender Konfigurationsoptionen)
Ack. Ich tendiere zu 2... Das liesse sich dann evtl. sogar komplett via MakeMaker realisieren. Hab Christian grad nen Anfang gemailt ;) -dnh -- [..] the Corporation decided that it was better to spend $N*1e6 on [..] than to spend $X*1e6 to [..] (where X << N from what I've heard). But at least now we're fully buzzword-compliant. -- Garrett Wollman in asr
Hallo David, hallo Ralf, hallo Leute, Am Mittwoch, 5. Februar 2003 18:26 schrieb David Haller:
On Wed, 05 Feb 2003, Ralf Corsepius wrote:
[Pfad zur Apache-Config]
Doch, das kann lustig werden ;)
Apropos: Wie waere's mit: `apxs -q sysconfdir` als default? Das sollte doch eigentlich meist klappen...
Denkste ;-) cb@tux:~> apxs -q sysconfdir bash: apxs: command not found cb@tux:~> pin apxs # gekürzt apache2-devel-2.0.40-12.i586.rpm: /usr/sbin/apxs2 apache-devel-1.3.26-39.i586.rpm: /usr/sbin/apxs Ganz so einfach ist es also doch nicht ;-) - apxs liegt es in /usr/sbin, was selten im User-Pfad sein dürfte - die wenigsten haben wohl apache-devel installiert - oder nutzen einige gar schon apache2? Dann müsste man nämlich apxs2 aufrufen. Fazit: Bei den meisten passt ~/public_html, der Rest (den ich < 2% schätze) hat selber dran gedreht und sollte fähig sein, das richtige Verzeichnis anzugeben ;-) [1] Gruß Christian Boltz PS: geänderte Makefiles liegen im Fontlinge-CVS. Wie man da dran kommt, ist auf http://sourceforge.net/cvs/?group_id=57266 erklärt (Modulname: fontlinge_rc). [1] Ich hab grade in der INSTALL einen entsprechenden Hinweis bei der Userinstallation eingebaut, das Thema sollte also geklärt sein ;-) -- .tsi neshcaweg lebanhcS red mhi eiw ,nebierhcs os redej run lloS senie nebatshcuB netsre ned hcodej nnad uD tsetllos esiewretneuqesnoK .nereileksunim seztaS [Andreas Kneib in suse-linux]
Hi, On 5 Feb 2003, Ralf Corsepius wrote:
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht.
$() .. Makefile-Variablen. ${} .. Shell/Environment-Variablen.
Manche "make"s unterscheiden da sehr streng, andere makes sind da etwas "lässiger" (GNU-make gehört "leider" dazu). Das kann zu "netten" Überraschungen führen, wenn man versucht mit gnu-make geschriebene, vorgeblich portable Makefiles auf anderen U*ixen zu verwenden.
Nein. $(string1) und ${string2} im makefiles sind laut POSIX _exakt_ dasselbe (selbe Auswertungsreihenfolge, selbe Sourcen, alles gleich). Um wirklich auf Shell-Variablen in den commands einer Regel zugreifen zu koennen muss man "$$hallo" schreiben, oder "$${hallo}". Das "$$" wird dann im Command zu "$" und leitet mithin eine ganz normale var-Expansion in shell ein. Womit du es moeglicherweise verwechselst ist, dass die Makros auch aus dem Environment kommen koennen. Also: % cat Makefile all: echo $(HALLO) echo ${HALLO} echo $$HALLO % make -s % make HALLO=huhu -s huhu huhu huhu % HALLO=huhu make -s huhu huhu huhu Aber: % cat Makefile all: for i in 1 2; do echo ${i}; done macht _nicht_ was man will, da 'i' als Makro ja nirgends definiert wird, mithin sind ${i} == $(i) immer leer. Hier will man auf die shell-variable 'i' zugreifen, und sie nicht von make auswerten lassen, also: all: for i in 1 2; do echo $$i; done oder all: for i in 1 2; do echo $${i}; done Ciao, Micha.
Am Mit, 2003-02-05 um 22.38 schrieb Michael Matz:
Hi,
On 5 Feb 2003, Ralf Corsepius wrote:
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht.
$() .. Makefile-Variablen. ${} .. Shell/Environment-Variablen.
Manche "make"s unterscheiden da sehr streng, andere makes sind da etwas "lässiger" (GNU-make gehört "leider" dazu). Das kann zu "netten" Überraschungen führen, wenn man versucht mit gnu-make geschriebene, vorgeblich portable Makefiles auf anderen U*ixen zu verwenden.
Nein. $(string1) und ${string2} im makefiles sind laut POSIX _exakt_ dasselbe (selbe Auswertungsreihenfolge, selbe Sourcen, alles gleich). Aha, das mag erklären, warum mir das Problem schon seit längerem nicht mehr begegnet ist.
Ich errinnere mich aber noch an Zeiten, in denen es anders war. Wenn ich mich nicht irre, gehörteb verschiedene Varianten von SunOS und Solaris-makes dazu. Ralf
Hi, On 6 Feb 2003, Ralf Corsepius wrote:
Nein. $(string1) und ${string2} im makefiles sind laut POSIX _exakt_ dasselbe (selbe Auswertungsreihenfolge, selbe Sourcen, alles gleich). Aha, das mag erklären, warum mir das Problem schon seit längerem nicht mehr begegnet ist.
Ich errinnere mich aber noch an Zeiten, in denen es anders war. Wenn ich mich nicht irre, gehörteb verschiedene Varianten von SunOS und Solaris-makes dazu.
Das ist natuerlich gut moeglich. Solaris Tools, wie die SunOS sh (ich nenne sie gerne SunOS shit), haben die irritierende und wie's scheint nicht kleinzukriegende Angewohnheit POSIX non-konform zu sein ;-) Ciao, Micha.
Hallo Ralf, hallo David, hallo Leute, Am Mittwoch, 5. Februar 2003 16:33 schrieb Ralf Corsepius:
Am Die, 2003-02-04 um 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:
Ich habe es mir zur Angewohnheit gemacht, dass ich moeglichst _immer_ ':=' verwende, es sei denn, ich will explizit, dass das zuzuweisende jedesmal ausgewertet wird...
Keine gute Idee. ':=' ist nicht portabel, weshalb es von Automake auch nicht verwendet wird.
Dann lass ich das mal bleiben ;-)
und geschweifte Klammern um die Variablennamen?
Oehm, ehrlich gesagt, weiss nicht.
$() .. Makefile-Variablen. ${} .. Shell/Environment-Variablen.
Manche "make"s unterscheiden da sehr streng, andere makes sind da etwas "lässiger" (GNU-make gehört "leider" dazu). Das kann zu "netten" Überraschungen führen, wenn man versucht mit gnu-make geschriebene, vorgeblich portable Makefiles auf anderen U*ixen zu verwenden.
Alles klar, also weiterhin $(...)
Und bin grad auch zu faulnachzuschauen. Das hab ich schlicht aus den autoconf-Makefiles... ;)
Automake-Makefiles, autoconf-Makefile's gibt es nicht ;)
*g*
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.
OK.
Für docdir? Wäre eine sinnvolle Möglichkeit. $(docdir) wird von den
Was jetzt? docdir oder docpath? Ich glaube fast, ich lasse beide zu ;-) docdir=... docpath=$(docdir) Sollte doch funktionieren, auch in der Form make install docpath=...
GNU-Standards nicht erfasst, ist somit frei wählbar. Was im Endeffekt wirklich sinnvoll ist, hängt vom Sinn und Zweck dieser Files ab.
Naja, Doku eben ;-) Wo wir es gerade von den Bezeichnungen für die Pfade haben: Wir verwenden u. a. DESTDIR=... Falls jemand ein RPM bauen will, kann er mit make install DESTDIR=/tmp/fontlinge-tmp/ "installieren". Gibts an DESTDIR auch was auszusetzen oder ist das OK so?
Außerdem heißt das Konfigurationsverzeichnis für den neuen Apache2 AFAIK /etc/apache2...
Nein, ist installationsabhängig bzw. Vendor-spezifisch, d.h. es kann buchstäblich irgendwo liegen
(RH z.B. verwendet /etc/httpd mit /etc/httpd/conf/httpd.conf und Modulkonfigurationen in /etc/httpd/conf.d/*.conf).
Evtl. koennte man da auch ein kleines "configure" schreiben, dass Pfade z.B. abfragt/rausfindet...
Ich würde hier schlicht und einfach eine configure-Option einführen (--with-httpd=<path> o.ä.) und dann den Pfad und die darin enthaltenen Dateien auf Verwendbarkeit für eure Zwecke testen.
Viel zu kompliziert ;-) Letztenendes kommt es nur darauf an, wo ein paar PHP-Dateien abgelegt werden sollen, und das ist per default (der wohl bei 98% der Installationen zutreffen dürfte) ~/public_html bei der Userinstallation. Die restlichen 2% haben es selbst geändert und sind demzufolge auch fähig, die Installation entsprechend mit Parametern zu steuern ;-)
Könnte schwierig werden, siehe oben ;-)
Och, nicht wirklich ;)
Doch, das kann lustig werden ;)
Stimmt. Vor allem, wenn ich an diverse Distris, Apache-Versionen und (vor allem) die Include-Direktive denke...
Wie meinte doch neulich ein OS/2 oder CygWin-User: PATH=C:\backspace\return;E:\tab\newline;D:\home W:\pakete\mypaket\configure --prefix=F:\fondlinge
*ROTFL*
Oder auch:
PATH="${HOME}/Oktoberfest 2003:$PATH" configure '--prefix=Auf geht\'s'
*LoL*
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).
Just don't!
OK, da hat mich auch David schon davon überzeugt.
Gibt es da irgendwelche Bedenken oder bessere Möglichkeiten?
Es gäbe viele Möglichkeiten, aber die von Euch scheinbar gewählte ist so ziemlich die Schlechteste (Sorry)
Kein Problem, ist ja berechtigte Kritik. (meine Lösung dazu hab ich ja schon in der Antwort auf Davids Mail geschrieben) Gruß Christian Boltz -- P.S.: In der kommenden Version sollen die besten Eigenschaften von Windows CE, Me und NT vereinigt werden zu "Windows CEMENT". Wenn das mal nicht'n stabiles OS wird. ;-))))) [Ratti in suse-linux]
Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz:
Hallo Ralf, hallo David, hallo Leute,
Am Mittwoch, 5. Februar 2003 16:33 schrieb Ralf Corsepius:
Am Die, 2003-02-04 um 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:
Ich habe es mir zur Angewohnheit gemacht, dass ich moeglichst _immer_ ':=' verwende, es sei denn, ich will explizit, dass das zuzuweisende jedesmal ausgewertet wird...
Keine gute Idee. ':=' ist nicht portabel, weshalb es von Automake auch nicht verwendet wird.
Dann lass ich das mal bleiben ;-) Kommt darauf an, ob ihr portable Makefiles wollt oder nicht. Wenn ihr GNU-make voraussetzt, oder "ein make, dass := kennt" spricht nichts dagegen auch ":=" zu verwenden.
Wenn ihr ausschliesslich auf GNU-Make setzen wollt, wäre es ausserdem noch eine Überlegung wert ob ihr eure Makefiles dann nicht in "GNUmakefile" nennen wollt.
Für docdir? Wäre eine sinnvolle Möglichkeit. $(docdir) wird von den
Was jetzt? docdir oder docpath? Ich würde docdir verwenden, da docpath mit einem Suchpfad verwechselt werden könnte (Ich bilde mir ein, mich erinnern zu können, dass die GNU-Standards oder ein damit verwandtes Dokument dazu einen Abschnitt beinhaltet)
GNU-Standards nicht erfasst, ist somit frei wählbar. Was im Endeffekt wirklich sinnvoll ist, hängt vom Sinn und Zweck dieser Files ab.
Naja, Doku eben ;-) Das meist ungelesene Zeugs in /usr/share/doc ... *g* ???
Was ich mit Sinn und Zweck meinte: Es gäbe noch andere Möglichkeiten als Dateien nach /usr/share/doc/XXX zu kopieren (z.B. scrollkeeper, z.B. die Doku in $pkgdatadir als in sich geschlossene Doku ablegen) Es kann auch sinnvoll sein, Doku formatabhängig an andere Stellen zu installieren (man-pages, info-pages, html-pages, xml-pages, pdf, ps. o.ä.).
Wo wir es gerade von den Bezeichnungen für die Pfade haben: Wir verwenden u. a. DESTDIR=... Falls jemand ein RPM bauen will, kann er mit make install DESTDIR=/tmp/fontlinge-tmp/ "installieren". Gibts an DESTDIR auch was auszusetzen oder ist das OK so? Nein, nur wenn man DESTDIR verwendet, sollte es als globaler Prefix vor allen sonstigen Pfaden bei der Installation verwendet werden.
$(INSTALL) xxx.h $(DESTDIR)/$(includedir)/xxx.h $(INSTALL) libxxx.a $(DESTDIR)/$(libdir)/libxxx.a o.ä. Ralf
Hallo Ralf, hallo Leute, Am Donnerstag, 6. Februar 2003 02:13 schrieb Ralf Corsepius:
Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz:
Am Mittwoch, 5. Februar 2003 16:33 schrieb Ralf Corsepius:
Am Die, 2003-02-04 um 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:
[...] Kommt darauf an, ob ihr portable Makefiles wollt oder nicht. Wenn ihr GNU-make voraussetzt, oder "ein make, dass := kennt" spricht nichts dagegen auch ":=" zu verwenden.
Wenn ihr ausschliesslich auf GNU-Make setzen wollt, wäre es ausserdem noch eine Überlegung wert ob ihr eure Makefiles dann nicht in "GNUmakefile" nennen wollt.
Ich würde sagen, so portabel wie möglich. Die Fontlinge bestehen ja "nur" aus einigen Perl-Scripten und einer WebGUI in PHP, gewürzt mit einer kräftigen Portion ImageMagick und MySQL als Unterbau ;-) Die Fontlinge sind also IMHO portabel (ungetestet), da sollten es die Makefiles auch sein.
Was jetzt? docdir oder docpath?
Ich würde docdir verwenden, da docpath mit einem Suchpfad verwechselt werden könnte (Ich bilde mir ein, mich erinnern zu können, dass die GNU-Standards oder ein damit verwandtes Dokument dazu einen Abschnitt beinhaltet)
Inzwischen hab ich die Makefiles so gebaut, dass docdir und docpath wahlweise verwendet werden können, da beide ja recht verbreitet zu sein scheinen ;-)
GNU-Standards nicht erfasst, ist somit frei wählbar. Was im Endeffekt wirklich sinnvoll ist, hängt vom Sinn und Zweck dieser Files ab.
Naja, Doku eben ;-)
Das meist ungelesene Zeugs in /usr/share/doc ... *g* ???
Ich zitiere aus einer dieser "meist ungelesenen" Dateien: | Don't even think about 'just starting it'! | Goodbye files! Ratti hat zwar anscheinend einen Hang zum Dramatischen ;-) aber ganz abwegig ist der Hinweis nicht ;-)
Was ich mit Sinn und Zweck meinte: Es gäbe noch andere Möglichkeiten als Dateien nach /usr/share/doc/XXX zu kopieren (z.B. scrollkeeper, z.B. die Doku in $pkgdatadir als in sich geschlossene Doku ablegen)
Es kann auch sinnvoll sein, Doku formatabhängig an andere Stellen zu installieren (man-pages, info-pages, html-pages, xml-pages, pdf, ps. o.ä.).
Von den diversen Ablagemöglichkeiten für Doku weiß ich noch nicht allzu viel ;-) - ich bleibe also vorläufig bei $(prefix)/share/doc/fontlinge Momentan haben wir an Doku folgendes: - die Standarddateien INSTALL README usw. - einige HTML-Dateien, die die Benutzung erklären (Offline-Version von http://www.gesindel.de ) - fontlinge_* --help
Wo wir es gerade von den Bezeichnungen für die Pfade haben: Wir verwenden u. a. DESTDIR=... Falls jemand ein RPM bauen will, kann er mit make install DESTDIR=/tmp/fontlinge-tmp/ "installieren". Gibts an DESTDIR auch was auszusetzen oder ist das OK so?
Nein, nur wenn man DESTDIR verwendet, sollte es als globaler Prefix vor allen sonstigen Pfaden bei der Installation verwendet werden.
$(INSTALL) xxx.h $(DESTDIR)/$(includedir)/xxx.h $(INSTALL) libxxx.a $(DESTDIR)/$(libdir)/libxxx.a
Alles klar, so hab ichs ;-) Gruß Christian Boltz --
...NACK -->ware MÄNNER nutzen BSD :;))) Weicheier! Ware Männer brauchen kein Betriebssystem, denen reicht ein Bios mit integrierten HEX-Editor ;-) [Dieter Franzke und Manfred Tremmel in suse-linux]
Am Fre, 2003-02-07 um 00.33 schrieb Christian Boltz:
Hallo Ralf, hallo Leute,
Am Donnerstag, 6. Februar 2003 02:13 schrieb Ralf Corsepius:
Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz:
Am Mittwoch, 5. Februar 2003 16:33 schrieb Ralf Corsepius:
Am Die, 2003-02-04 um 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:
[...] Was jetzt? docdir oder docpath?
Ich würde docdir verwenden, da docpath mit einem Suchpfad verwechselt werden könnte (Ich bilde mir ein, mich erinnern zu können, dass die GNU-Standards oder ein damit verwandtes Dokument dazu einen Abschnitt beinhaltet)
Hab's gefunden (info standards -> Documentation): .. Please do not use the term "pathname" that is used in Unix documentation; use "file name" (two words) instead. We use the term "path" only for search paths, which are lists of directory names. ..
Nein, nur wenn man DESTDIR verwendet, sollte es als globaler Prefix vor allen sonstigen Pfaden bei der Installation verwendet werden.
$(INSTALL) xxx.h $(DESTDIR)/$(includedir)/xxx.h $(INSTALL) libxxx.a $(DESTDIR)/$(libdir)/libxxx.a
Alles klar, so hab ichs ;-)
Aber ich nicht! Mein Beispiel ist falsch, richtig wäre: $(DESTDIR)$(includedir) Ohne '/' zwischen $(DESTDIR) und Rest. Ralf
Hallo Ralf, hallo Leute, Am Freitag, 7. Februar 2003 05:41 schrieb Ralf Corsepius:
Am Fre, 2003-02-07 um 00.33 schrieb Christian Boltz:
Hallo Ralf, hallo Leute,
Am Donnerstag, 6. Februar 2003 02:13 schrieb Ralf Corsepius:
Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz: [...]
Was jetzt? docdir oder docpath?
Ich würde docdir verwenden, da docpath mit einem Suchpfad verwechselt werden könnte (Ich bilde mir ein, mich erinnern zu können, dass die GNU-Standards oder ein damit verwandtes Dokument dazu einen Abschnitt beinhaltet)
Hab's gefunden (info standards -> Documentation): .. Please do not use the term "pathname" that is used in Unix documentation; use "file name" (two words) instead. We use the term "path" only for search paths, which are lists of directory names. ..
Ah ja. Dann erwähn ich lieber docdir in der INSTALL ;-) [ $(DESTDIR) ]
$(INSTALL) xxx.h $(DESTDIR)/$(includedir)/xxx.h
Alles klar, so hab ichs ;-)
Aber ich nicht!
Mein Beispiel ist falsch, richtig wäre: $(DESTDIR)$(includedir)
Ohne '/' zwischen $(DESTDIR) und Rest.
Hmm, ob das eine gute Idee ist? Der Vorteil dürfte eher optischer Natur sein (Vermeidung von // im fertigen Verzeichnisnamen). Oder glaubst Du, dass jemand einen _relativen_ Pfad verwenden möchte? Halte ich für sehr unwahrscheinlich... (und sogar das ginge: DESTDIR=.) Allerdings macht das Ganze Probleme, wenn z. B. $(prefix) nicht mit einem / beginnt :-| (DESTDIR=/tmp/fontlinge-root prefix=usr/local legt das Verzeichnis /tmp/fontlinge-rootusr/local an :-| ) Gruß Christian Boltz -- Wenn schon, dann höchstens Homo Sapiens Sapiens XEmacensis, die Entwicklungslinie, die im Laufe der Evolution sieben Finger an jeder Hand entwickelt hat. Und das alles nur um alle Tastenkürzel zur Bedienung von XEmacs nutzen zu können. [T. Templin über David Haller]
Moin, Am Fre, 2003-02-07 um 00.33 schrieb Christian Boltz:
Am Donnerstag, 6. Februar 2003 02:13 schrieb Ralf Corsepius:
Wenn ihr ausschliesslich auf GNU-Make setzen wollt, wäre es ausserdem noch eine Überlegung wert ob ihr eure Makefiles dann nicht in "GNUmakefile" nennen wollt.
Ich würde sagen, so portabel wie möglich. Die Fontlinge bestehen ja "nur" aus einigen Perl-Scripten und einer WebGUI in PHP, gewürzt mit einer kräftigen Portion ImageMagick und MySQL als Unterbau ;-) Die Fontlinge sind also IMHO portabel (ungetestet), da sollten es die Makefiles auch sein.
"Portabel" innerhalb einer Linux/Unix-Umgebung. Ich gehe schon davon aus, das Pfade mit "/" getrennt werden und nicht mit "\" (Win) oder ":" (Mac). Bill tut nix für mich, wieso soll ich was für Bill tun? Gruß, Ratti -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
Hallo, On Fri, 07 Feb 2003 at 18:40 (+0100), Ratti wrote:
Am Fre, 2003-02-07 um 00.33 schrieb Christian Boltz:
Am Donnerstag, 6. Februar 2003 02:13 schrieb Ralf Corsepius:
Wenn ihr ausschliesslich auf GNU-Make setzen wollt, wäre es ausserdem noch eine Überlegung wert ob ihr eure Makefiles dann nicht in "GNUmakefile" nennen wollt.
Ich würde sagen, so portabel wie möglich. Die Fontlinge bestehen ja "nur" aus einigen Perl-Scripten und einer WebGUI in PHP, gewürzt mit einer kräftigen Portion ImageMagick und MySQL als Unterbau ;-) Die Fontlinge sind also IMHO portabel (ungetestet), da sollten es die Makefiles auch sein.
"Portabel" innerhalb einer Linux/Unix-Umgebung. Ich gehe schon davon aus, das Pfade mit "/" getrennt werden und nicht mit "\" (Win) oder ":" (Mac).
Windows versteht den Schraegstrich als Verzeichnistrenner auch, das ist also kein grosses Problem. Welches 'Laufwerk' mit / verwendet wird weiss ich jetzt auch nicht, ich vermute aber mal C:\. Probleme koennte es im Zusammenhang mit Perl geben, wenn man bei Dateien nicht zwischen Binaermodus und Textmodus unterscheidet: Beim Textmodus wird aus einem \n ein \r\n. Entsprechend umgeschaltet wird mit binmode FILEHANDLE, z. B. binmode STDOUT. Und was unter Windows nuetzlich ist schadet auch unter Unix nicht, man sollte also diese Unterscheidung sowieso vornehmen.
Bill tut nix für mich, wieso soll ich was für Bill tun?
Und was bitteschoen hat Bill (ich nehme an Du meinst Bill Gates) davon, wenn Du Fontline fuer Windows portierst. Gruß, Bernhard --
Linux is not user-friendly. It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
Moin, Am Fre, 2003-02-07 um 19.13 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 18:40 (+0100), Ratti wrote:
"Portabel" innerhalb einer Linux/Unix-Umgebung. Ich gehe schon davon aus, das Pfade mit "/" getrennt werden und nicht mit "\" (Win) oder ":" (Mac).
Windows versteht den Schraegstrich als Verzeichnistrenner auch, das ist also kein grosses Problem.
Ne, geht nicht wirklich. Meine Mac-User legen gerne mal auf NTFS-Freigaben Dateien an , die Slashes, Sterne oder Anführungszeichen enthalten. Das wird von Win nicht wirklich verweigert, haut aber vorne und hinten nicht hin. Desweiteren Dateinamen, die mit Spaces enden, und und und...
Welches 'Laufwerk' mit / verwendet wird weiss ich jetzt auch nicht, ich vermute aber mal C:\.
Bringt uns trotzdem nicht weiter. Ich verwende Konstruktionen wie $zielpfad= "$HOME/fontbase/$kategorie/$Anfangsbuchstabe/$fontname" und umgekehrt $pfadelemente=split('/',$pfad); (Wir brauchen jetzt nicht über Quoting und Sonderzeichen reden. Das sind nur Beispiele) Spätestens letzteres geht schief, da $pfad z.B. über find ermittelt wurde.
Probleme koennte es im Zusammenhang mit Perl geben, wenn man bei Dateien nicht zwischen Binaermodus und Textmodus unterscheidet: Beim Textmodus
Textdateien haben wir eh nicht. Und alle relevanten Editoren auf allen relevanten Plattformen können sowieso damit umgehen.
Bill tut nix für mich, wieso soll ich was für Bill tun?
Und was bitteschoen hat Bill (ich nehme an Du meinst Bill Gates) davon, wenn Du Fontline fuer Windows portierst.
Fontlin*g*e bitte. Soviel Zeit muß sein. Betonung als deutsches Wort, wie "Engerlinge" :-) Nun zunächst mal kann Bill seine Fonts per Hand sortieren, Bätsch. Und er muß Millionen trauriger Menschen erklären, wieso das unter Linux geht und unter WIndows nicht. Und dann kaufen alle Leute Linux-Distris, und Bill geht pleite und muß hungern, und ich reite in den Sonnenuntergang. Soweit der Plan. Für Version 2.0 planen wir dann die Weltherrschaft. Aber jetzt ist erstmal Wochenende. Gruß, Ratti -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Fri, 07 Feb 2003 at 20:39 (+0100), Ratti wrote:
Am Fre, 2003-02-07 um 19.13 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 18:40 (+0100), Ratti wrote:
"Portabel" innerhalb einer Linux/Unix-Umgebung. Ich gehe schon davon aus, das Pfade mit "/" getrennt werden und nicht mit "\" (Win) oder ":" (Mac).
Windows versteht den Schraegstrich als Verzeichnistrenner auch, das ist also kein grosses Problem.
Ne, geht nicht wirklich. Meine Mac-User legen gerne mal auf NTFS-Freigaben Dateien an , die Slashes, Sterne oder Anführungszeichen enthalten. Das wird von Win nicht wirklich verweigert, haut aber vorne und hinten nicht hin. Desweiteren Dateinamen, die mit Spaces enden, und und und...
Keine Ahnung wie das Zusammenspiel von NTFS-Freigaben im Zusammenhang mit MacOS funktioniert, die Windows-API versteht den Schraegstrich als Verzeichnistrenner trotzdem. Kannst Du gerne unter Windows direkt ausprobieren, habe ich naemlich auch schon in Programmierbuechern gelesen (weil man den \ in gaengigen Sprachen ja maskieren muss).
Welches 'Laufwerk' mit / verwendet wird weiss ich jetzt auch nicht, ich vermute aber mal C:\.
Bringt uns trotzdem nicht weiter. Ich verwende Konstruktionen wie
$zielpfad= "$HOME/fontbase/$kategorie/$Anfangsbuchstabe/$fontname"
und umgekehrt
$pfadelemente=split('/',$pfad);
(Wir brauchen jetzt nicht über Quoting und Sonderzeichen reden. Das sind nur Beispiele)
Spätestens letzteres geht schief, da $pfad z.B. über find ermittelt wurde.
Ok, das ist ja was anderes. Aber der Schraegstrich geht.
Probleme koennte es im Zusammenhang mit Perl geben, wenn man bei Dateien nicht zwischen Binaermodus und Textmodus unterscheidet: Beim Textmodus
Textdateien haben wir eh nicht. Und alle relevanten Editoren auf allen relevanten Plattformen können sowieso damit umgehen.
Standard in Perl ist aber Textmodus, d. h. Du musst explizit in den Binaermodus umschalten, wenn Du z. B. bei Konstrukten wie open (SRC, "/home/bwalle/test.jpg") or die " ... "; open (DST, "/home/bwalle/test2.jpg") or die " ... "; while (<SRC>) { print DST $_; } close SRC; close DST; keine verkrueppelten Bilder haben willst.
Bill tut nix für mich, wieso soll ich was für Bill tun?
Und was bitteschoen hat Bill (ich nehme an Du meinst Bill Gates) davon, wenn Du Fontline fuer Windows portierst.
Fontlin*g*e bitte. Soviel Zeit muß sein. Betonung als deutsches Wort, wie "Engerlinge" :-)
War nur ein Fipptehler.
Nun zunächst mal kann Bill seine Fonts per Hand sortieren, Bätsch. Und er muß Millionen trauriger Menschen erklären, wieso das unter Linux geht und unter WIndows nicht. Und dann kaufen alle Leute Linux-Distris, und Bill geht pleite und muß hungern, und ich reite in den Sonnenuntergang. Soweit der Plan. Für Version 2.0 planen wir dann die Weltherrschaft. Aber jetzt ist erstmal Wochenende.
:-)
Gruß,
Bernhard
--
If you really want pure ASCII, save it as text... or browse
it with your favorite browser...
-- Alexandre Maret
Am Fre, 2003-02-07 um 20.58 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 20:39 (+0100), Ratti wrote:
Am Fre, 2003-02-07 um 19.13 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 18:40 (+0100), Ratti wrote:
Windows versteht den Schraegstrich als Verzeichnistrenner auch, das ist also kein grosses Problem.
Ne, geht nicht wirklich. Meine Mac-User legen gerne mal auf NTFS-Freigaben Dateien an , die Slashes, Sterne oder Anführungszeichen enthalten. Das wird von Win nicht wirklich verweigert, haut aber vorne und hinten nicht hin. Desweiteren Dateinamen, die mit Spaces enden, und und und...
Keine Ahnung wie das Zusammenspiel von NTFS-Freigaben im Zusammenhang mit MacOS funktioniert, die Windows-API versteht den Schraegstrich als Verzeichnistrenner trotzdem. Kannst Du gerne unter Windows direkt ausprobieren, habe ich naemlich auch schon in Programmierbuechern gelesen (weil man den \ in gaengigen Sprachen ja maskieren muss).
Definiere "funktioniert". Wenn du Windows als OS definierst, so wie "Linux ist nur der Kernel", dann ja. Wenn du Windows als das Gesamtsystem definierst wie "Ich kann Photoshop-Dateien auch unter WIndows öffnen", dann nein. Spätestens beim CD-Brennen oder bei der Freigabe über das Netzwerk für andere OSse gibt es massenhaft Ärger. Vergleichbar: Kann Linux Umbrüche in Dateinamen? Ja, kann es. Man muß nur korrekt escapen. Nein, kann es nicht, weil ein guter Teil der Tools die Grätsche macht.
Standard in Perl ist aber Textmodus, d. h. Du musst explizit in den Binaermodus umschalten, wenn Du z. B. bei Konstrukten wie
open (SRC, "/home/bwalle/test.jpg") or die " ... "; open (DST, "/home/bwalle/test2.jpg") or die " ... "; while (<SRC>) { print DST $_; } close SRC; close DST;
keine verkrueppelten Bilder haben willst.
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`; (Auch hier Escaping mal außen vor) Ich bin damit nicht glücklich, aber das die Fontlinge im weitesten Sinne ein Archivierungstool sind, kann es nicht angehen, daß sie Properties einer Datei verändern (Die dadurch z.B. immer wieder neu ins Backup geraten würde, obwohl sie nur die Position verändert hat, was häufig nicht gewünscht ist) Gruß, Ratti -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Am Fre, 2003-02-07 um 20.58 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 20:39 (+0100), Ratti wrote:
Am Fre, 2003-02-07 um 19.13 schrieb Bernhard Walle:
On Fri, 07 Feb 2003 at 18:40 (+0100), Ratti wrote:
Windows versteht den Schraegstrich als Verzeichnistrenner auch, das ist also kein grosses Problem.
Ne, geht nicht wirklich. Meine Mac-User legen gerne mal auf NTFS-Freigaben Dateien an , die Slashes, Sterne oder Anführungszeichen enthalten. Das wird von Win nicht wirklich verweigert, haut aber vorne und hinten nicht hin. Desweiteren Dateinamen, die mit Spaces enden, und und und...
Keine Ahnung wie das Zusammenspiel von NTFS-Freigaben im Zusammenhang mit MacOS funktioniert, die Windows-API versteht den Schraegstrich als Verzeichnistrenner trotzdem. Kannst Du gerne unter Windows direkt ausprobieren, habe ich naemlich auch schon in Programmierbuechern gelesen (weil man den \ in gaengigen Sprachen ja maskieren muss).
Definiere "funktioniert". Wenn du Windows als OS definierst, so wie "Linux ist nur der Kernel", dann ja.
Ich meinte im Quellcode von Programmen und nicht in irgendwelchen Eingabeaufforderungen von Anwendungen. Wenn ich bspw. in C file_ptr = fopen("C:/eigene~1/test.txt", "r"); schreibe, dann funktioniert das (IIRC).
Wenn du Windows als das Gesamtsystem definierst wie "Ich kann Photoshop-Dateien auch unter WIndows öffnen", dann nein. Spätestens beim CD-Brennen oder bei der Freigabe über das Netzwerk für andere OSse gibt es massenhaft Ärger.
Ich habe unter Windows noch nie CDs gebrannt und von Netzwerken habe ich auch wenig Ahnung. ;-)
Vergleichbar: Kann Linux Umbrüche in Dateinamen? Ja, kann es. Man muß nur korrekt escapen.
Stimmt.
Nein, kann es nicht, weil ein guter Teil der Tools die Grätsche macht.
Ich wuerde eher sagen: Es ist nicht empfehlenswert, Zeilenumbrueche in Dateinamen zu verwenden weil viele Programme unnoetig Probleme bereiten.
Standard in Perl ist aber Textmodus, d. h. Du musst explizit in den Binaermodus umschalten, wenn Du z. B. bei Konstrukten wie
open (SRC, "/home/bwalle/test.jpg") or die " ... "; open (DST, "/home/bwalle/test2.jpg") or die " ... "; while (<SRC>) { print DST $_; } close SRC; close DST;
keine verkrueppelten Bilder haben willst.
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher. Gruß, Bernhard -- "Der Neid ist die aufrichtigste Form der Anerkennung." -- Wilhelm Busch
Moin, Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Ich wuerde eher sagen: Es ist nicht empfehlenswert, Zeilenumbrueche in Dateinamen zu verwenden weil viele Programme unnoetig Probleme bereiten.
Ja, und genau das meinte ich mit "Windows kann kein "/" im Dateinamen. "Unnötige Probleme" heisst ja, das irgendwo irgendwas nciht funktioniert. Daher machen die Fontlinge beim generieren von Dateinamen ein s/\W/_/gs;
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben. Ich bevorzuge b). Gerade bei Fonts ist es so, daß häufig irgendwelche Leute irgendwo einen Fonteditor ausgraben und einen Haufen Quatsch anrichten. Dieser Quatsch wandert dann zusammen mit irgendwelchen Jobs in den eigenen Datenbestand. Du hast dann 12 Helveticas. Davon sind 2 einfach kaputt, drei weitere haben keine deutschen Umlaute, und eine hat Umlaute auf dem Bildschirm - aber nciht im Druck. Gargl. In einer reinen Linux-Umgebung würden sich die Freaks wohl MD5-Checksummen zuwerfen, um festzustellen, wer welche hat. In einer reinen Anwenderumgebung nennt man sich einfach das Dateidatum ("Die von 12/97!") und gut ist. Das ist in der Praxis eine gute Lösung. Wenn ich jetzt ständig neue Files generiere, mag den technischen Ansprüchen genüge getan sein - in der Praxis ist es ein Haufen Schrott, sonst nix. =%-) (Ich denke gerade an eine ehemlige Hamburger Mailbox, die automatischen Dateiupload erlaubte und bei Duplikaten einfach eine laufende Nummer anhing. Gab es "Programm-2.1.zip" schon, wurde das Archiv unter "Programm-2.1-1.zip" gespeichert. Irgendwie gab es da immer neuere Versionen als anderswo... Nicht alles, was technisch korrekt ist, ist auch praktisch verwertbar.[1] :-) (und umgekehrt) Gruß, Ratti (Oder, damals, RED RAT in besagter Box :-) ) [1] Damals (und außerhalb von Linux) war eben noch nicht alles so standardisiert wie heute. -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Sat, 08 Feb 2003 at 14:36 (+0100), Ratti wrote:
Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Ich wuerde eher sagen: Es ist nicht empfehlenswert, Zeilenumbrueche in Dateinamen zu verwenden weil viele Programme unnoetig Probleme bereiten.
Ja, und genau das meinte ich mit "Windows kann kein "/" im Dateinamen. "Unnötige Probleme" heisst ja, das irgendwo irgendwas nciht funktioniert. Daher machen die Fontlinge beim generieren von Dateinamen ein s/\W/_/gs;
Nein, es heisst, dass es _unter_bestimmten_Umstaenden_ nicht funktioniert. Natuerlich ist es sinnvoll solche Zeichen mit einem Unterstrich zu escapen.
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben.
Ich bevorzuge b).
Man kann ja zunaechst pruefen, ob es sich um eine GNU-Umgebung handelt und dann die ensprechenden Befehle setzen, d. h. wenn das OS das Feature bietet, dann nimmt man -a her, ansonsten laesst man es sein. Immer noch besser als gar nichts. Ansonsten wuerde sich anbieten, das Ganze ueber tar nachzubilden. Ich weiss die entsprechenden Parameter nicht auswendig, vielleicht lesen hier irgendwelche Unix-Administratoren mit. Irgendwie habe ich im Hinterkopf, dass man sowas ueber tar-Pipes machen kann (mit Beibehaltung aller Attribute). Dass der Befehl umstaendlich ist kann Dir ja egal sein, Du musst ihn ja nicht auswendig koennen. Ob es sich um eine GNU-Erweiterung handelt weiss ich immer noch nicht, ich habe mich aber mal an einem HP_UX-System eingeloggt und in dessen Manpage nachgesehen, von -a steht da jedenfalls nichts.
Gerade bei Fonts ist es so, daß häufig irgendwelche Leute irgendwo einen Fonteditor ausgraben und einen Haufen Quatsch anrichten. Dieser Quatsch wandert dann zusammen mit irgendwelchen Jobs in den eigenen Datenbestand. Du hast dann 12 Helveticas. Davon sind 2 einfach kaputt, drei weitere haben keine deutschen Umlaute, und eine hat Umlaute auf dem Bildschirm - aber nciht im Druck. Gargl.
-> kaputte Schriften einfach loeschen. ;-)
In einer reinen Linux-Umgebung würden sich die Freaks wohl MD5-Checksummen zuwerfen, um festzustellen, wer welche hat. In einer reinen Anwenderumgebung nennt man sich einfach das Dateidatum ("Die von 12/97!") und gut ist. Das ist in der Praxis eine gute Lösung. Wenn ich jetzt ständig neue Files generiere, mag den technischen Ansprüchen genüge getan sein - in der Praxis ist es ein Haufen Schrott, sonst nix. =%-)
Ich nehme oft die Dateigroesse als Vergleichskriterium. Gruß, Bernhard -- "Act like a dumbshit and they'll treat you as an equal." -- Ivan E. Moore II
Am Sam, 2003-02-08 um 15.25 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 14:36 (+0100), Ratti wrote:
Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Ich wuerde eher sagen: Es ist nicht empfehlenswert, Zeilenumbrueche in Dateinamen zu verwenden weil viele Programme unnoetig Probleme bereiten.
Ja, und genau das meinte ich mit "Windows kann kein "/" im Dateinamen. "Unnötige Probleme" heisst ja, das irgendwo irgendwas nciht funktioniert. Daher machen die Fontlinge beim generieren von Dateinamen ein s/\W/_/gs;
Nein, es heisst, dass es _unter_bestimmten_Umstaenden_ nicht funktioniert. Natuerlich ist es sinnvoll solche Zeichen mit einem Unterstrich zu escapen.
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben.
Ich bevorzuge b). Es liegt bei Dir. Ich bevorzuge
c) Portable Lösungen ("Schreib deinen Code so, dass das Problem erst gar nicht auftritt")
Man kann ja zunaechst pruefen, ob es sich um eine GNU-Umgebung handelt Ein besserer Ansatz wäre, zu prüfen, ob ein System ein Feature bietet und es dann zu nutzen, wenn dieses Feature Vorteile bietet, nicht wie Du vorschlägst, auf "GNU" oder "Linux" o.ä. zu testen.
und dann die ensprechenden Befehle setzen, d. h. wenn das OS das Feature bietet, dann nimmt man -a her, ansonsten laesst man es sein. Immer noch besser als gar nichts. Ansonsten wuerde sich anbieten, das Ganze ueber tar nachzubilden. Ja, das ist eine gängige Lösung für dieses Problem.
Eine andere Lösung wäre, sich gar nicht erst auf cp -a einzulassen und sich darauf zu verlassen, dass User ihre umasks vernünftig gesetzt haben (cp -a macht ausser als "root" sowieso nur sehr selten Sinn) Eine weitere Lösung wäre, statt cp ein BSD-install-kompatibles "install"-Programm/Script zu verwenden. Autoconf sucht standardmässig nach einem solchen und verwendet es falls es eines findet, und greift, falls es keines findet auf sein install-sh Script zurück.
Ob es sich um eine GNU-Erweiterung handelt weiss ich immer noch nicht,
Ich weiss es auch nicht, ich kann Dir aber sagen, dass alles ausser .. cp [ -ip ] filename1 filename2 cp -rR [ -ip ] directory1 directory2 cp [ -iprR ] filename ... directory .. nicht portabel ist.
ich habe mich aber mal an einem HP_UX-System eingeloggt und in dessen Manpage nachgesehen, von -a steht da jedenfalls nichts. Der Auszug oben stammt aus einer SunOS4-Manpage (SunOS4 stellt ungefähr den kleinsten gemeinsamen Nenner der Shellprogrammierung dar.)
Ralf
Hallo, On Sat, 08 Feb 2003 at 17:53 (+0100), Ralf Corsepius wrote:
Am Sam, 2003-02-08 um 15.25 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 14:36 (+0100), Ratti wrote:
Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Ich wuerde eher sagen: Es ist nicht empfehlenswert, Zeilenumbrueche in Dateinamen zu verwenden weil viele Programme unnoetig Probleme bereiten.
Ja, und genau das meinte ich mit "Windows kann kein "/" im Dateinamen. "Unnötige Probleme" heisst ja, das irgendwo irgendwas nciht funktioniert. Daher machen die Fontlinge beim generieren von Dateinamen ein s/\W/_/gs;
Nein, es heisst, dass es _unter_bestimmten_Umstaenden_ nicht funktioniert. Natuerlich ist es sinnvoll solche Zeichen mit einem Unterstrich zu escapen.
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben.
Ich bevorzuge b). Es liegt bei Dir. Ich bevorzuge
c) Portable Lösungen ("Schreib deinen Code so, dass das Problem erst gar nicht auftritt")
Man kann ja zunaechst pruefen, ob es sich um eine GNU-Umgebung handelt Ein besserer Ansatz wäre, zu prüfen, ob ein System ein Feature bietet und es dann zu nutzen, wenn dieses Feature Vorteile bietet, nicht wie Du vorschlägst, auf "GNU" oder "Linux" o.ä. zu testen.
Und wie testet man sowas (in diesem Fall) zuverlaessig? Einfach cp -a ausfuehren und Fehlercodes ueberpruefen? Wohl eher nicht.
ich habe mich aber mal an einem HP_UX-System eingeloggt und in dessen Manpage nachgesehen, von -a steht da jedenfalls nichts. Der Auszug oben stammt aus einer SunOS4-Manpage (SunOS4 stellt ungefähr den kleinsten gemeinsamen Nenner der Shellprogrammierung dar.)
Gibt's die irgendwo im Internet? Gruß, Bernhard -- Real Men don't make backups. They upload it via ftp and let the world mirror it. -- Linus Torvalds
Am Sam, 2003-02-08 um 19.49 schrieb Bernhard Walle:
Hallo,
On Sat, 08 Feb 2003 at 17:53 (+0100), Ralf Corsepius wrote:
Am Sam, 2003-02-08 um 15.25 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 14:36 (+0100), Ratti wrote:
Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 10:51 (+0100), Ratti wrote:
Stimmt. Da ich aber kein Perl-Modul gefunden habe, welches in der Lage wäre, Dateien zu kopieren bei vollständiger Beibehaltung der Attribute, mache ich sowas ohnehin über die Shell: `cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben.
Ich bevorzuge b).
Es liegt bei Dir. Ich bevorzuge
c) Portable Lösungen ("Schreib deinen Code so, dass das Problem erst gar nicht auftritt")
Man kann ja zunaechst pruefen, ob es sich um eine GNU-Umgebung handelt Ein besserer Ansatz wäre, zu prüfen, ob ein System ein Feature bietet und es dann zu nutzen, wenn dieses Feature Vorteile bietet, nicht wie Du vorschlägst, auf "GNU" oder "Linux" o.ä. zu testen.
Und wie testet man sowas (in diesem Fall) zuverlaessig? Einfach cp -a ausfuehren und Fehlercodes ueberpruefen? Wohl eher nicht. Das wäre eine prinzipielle Möglichkeit und kann, wie Du erkannt hast, im Detail schnell sehr komplex werden.
Nur ist "cp -a" ein Klassiker unter den Portabilitätsproblemen, zu dem es eigentlich keine wirkliche Lösung gibt. Ausserdem kann man durchaus der Meinung sein, dass "cp -a" generell keinen Sinn in Makefiles macht und sich eigentlich immer vermeiden lässt.
ich habe mich aber mal an einem HP_UX-System eingeloggt und in dessen Manpage nachgesehen, von -a steht da jedenfalls nichts. Der Auszug oben stammt aus einer SunOS4-Manpage (SunOS4 stellt ungefähr den kleinsten gemeinsamen Nenner der Shellprogrammierung dar.)
Gibt's die irgendwo im Internet? Nicht, dass ich wüsste :-)
Ralf
Moin, Am Son, 2003-02-09 um 00.10 schrieb Ralf Corsepius:
Nur ist "cp -a" ein Klassiker unter den Portabilitätsproblemen, zu dem es eigentlich keine wirkliche Lösung gibt.
Ausserdem kann man durchaus der Meinung sein, dass "cp -a" generell keinen Sinn in Makefiles macht und sich eigentlich immer vermeiden lässt.
Aufwachen, hier geht's nicht mehr um Makefiles. :-))) Es geht darum innerhalb des normalen Programmablaufs Dateien zu kopieren, ohne daß das Änderungsdatum der Datei gesetzt wird, weil das bei Fonts eine wichtige Info ist, die bleiben muß. Mich wundert schon, daß es da in perl nix gibt. Ist aber wohl so. Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Son, 09 Feb 2003 at 22:41 (+0100), Jörg Roßdeutscher wrote: [...]
Es geht darum innerhalb des normalen Programmablaufs Dateien zu kopieren, ohne daß das Änderungsdatum der Datei gesetzt wird, weil das bei Fonts eine wichtige Info ist, die bleiben muß.
Mich wundert schon, daß es da in perl nix gibt. Ist aber wohl so.
Wozu Perl, wenns mit den Linux-Bordmitteln läuft? cd /quelle; find . -type f -print | cpio -pdmu /ziel (Läuft auf allen mir bekannten *nixen und *nuxen). Jan
Hallo Jan, Wieder online? *schoen* On Sun, 09 Feb 2003, Jan Trippler wrote:
On Son, 09 Feb 2003 at 22:41 (+0100), Jörg Roßdeutscher wrote: [...]
Es geht darum innerhalb des normalen Programmablaufs Dateien zu kopieren, ohne daß das Änderungsdatum der Datei gesetzt wird, weil das bei Fonts eine wichtige Info ist, die bleiben muß.
Mich wundert schon, daß es da in perl nix gibt. Ist aber wohl so.
Wozu Perl, wenns mit den Linux-Bordmitteln läuft?
cd /quelle; find . -type f -print | cpio -pdmu /ziel
(Läuft auf allen mir bekannten *nixen und *nuxen).
Es geht um einen Aufruf _aus_ einem perl-script heraus (fontlinge), wenn das also perl-intern gehen wuerde waere das besser ;) Achso: ich hab's jetzt nicht angeschaut, aber ich vermute mal, dass man via stat auslesen und dann wieder setzen evtl. was drehen koennte... -dnh PS@Jan: http://www.dhaller.de/linux/headmidtail -- Now you're being rational. Stop that at once! -- P. Tomblin
On Mon, 10 Feb 2003 at 00:52 (+0100), David Haller wrote:
Hallo Jan,
Wieder online? *schoen*
Schon seit 'ner Woche - nich gemerkt? *grummel*
On Sun, 09 Feb 2003, Jan Trippler wrote: [...]
cd /quelle; find . -type f -print | cpio -pdmu /ziel
(Läuft auf allen mir bekannten *nixen und *nuxen).
Es geht um einen Aufruf _aus_ einem perl-script heraus (fontlinge), wenn das also perl-intern gehen wuerde waere das besser ;)
Ah ja - dann bleibt wohl nur Archive::Tar: http://search.cpan.org/author/KANE/Archive-Tar-0.23/lib/Archive/Tar.pm Zu cpio (war schon immer ein Stiefkind) habe ich leider nix gefunden :-(
Achso: ich hab's jetzt nicht angeschaut, aber ich vermute mal, dass man via stat auslesen und dann wieder setzen evtl. was drehen koennte...
Hab ich schon geguckt - man kann mittels File::stat nur lesen. Aber es gibt ja File::Touch: http://search.cpan.org/author/NWETTERS/File-Touch-0.01/Touch.pm Ja-Ach wie gut das niemand weiss, was CPAN heisst-n
Kommt noch - im Moment führe ich noch Krieg gegen meine neue Wohnung ;-)
Hallo, On Mon, 10 Feb 2003, Jan Trippler wrote:
On Mon, 10 Feb 2003 at 00:52 (+0100), David Haller wrote:
Wieder online? *schoen*
Schon seit 'ner Woche - nich gemerkt? *grummel*
Ne ;(
On Sun, 09 Feb 2003, Jan Trippler wrote: [...]
cd /quelle; find . -type f -print | cpio -pdmu /ziel
(Läuft auf allen mir bekannten *nixen und *nuxen).
Es geht um einen Aufruf _aus_ einem perl-script heraus (fontlinge), wenn das also perl-intern gehen wuerde waere das besser ;)
Ah ja - dann bleibt wohl nur Archive::Tar: http://search.cpan.org/author/KANE/Archive-Tar-0.23/lib/Archive/Tar.pm
Jup.
Zu cpio (war schon immer ein Stiefkind) habe ich leider nix gefunden :-(
Ich auch nicht.
Achso: ich hab's jetzt nicht angeschaut, aber ich vermute mal, dass man via stat auslesen und dann wieder setzen evtl. was drehen koennte...
Hab ich schon geguckt - man kann mittels File::stat nur lesen. Aber es gibt ja File::Touch: http://search.cpan.org/author/NWETTERS/File-Touch-0.01/Touch.pm
Ja-Ach wie gut das niemand weiss, was CPAN heisst-n
"Comprehensive Perl Archive Network" Und dann ist da noch CTAN :)
PS@Jan: http://www.dhaller.de/linux/headmidtail Kommt noch - im Moment führe ich noch Krieg gegen meine neue Wohnung ;-)
Ok ;) -dnh -- <rumzick> ist David den gemacht. Es also _nur_ Vorschlag _Das_ mir Du an mich Dann schon Du, mich zum Geh hin einem den Du ganz, Kerl, das? denn überhaupt? zärtlicher ja? mehr er oder was? mir Hause -- Moss in suse-talk
Moin, Am Mon, 2003-02-10 um 12.57 schrieb David Haller:
On Mon, 10 Feb 2003, Jan Trippler wrote:
Ah ja - dann bleibt wohl nur Archive::Tar: http://search.cpan.org/author/KANE/Archive-Tar-0.23/lib/Archive/Tar.pm
Jup.
Jungens, helft doch mal 'nem alten Mann beim Denken. Ich sehe da Methoden zum ein- und auspacken von tar-Archiven, aber nicht den segensbringenden cp-Ersatz. Ich nehme mal an, daß einer dieser Befehle, wenn ich morgen nicht-müde nochmal draufgucke, in der Lage ist, ähnlich wie tar eine Datei mitsamt ihrer stati durchzuschieben wie tar -c dies_hier/ | tar -x dahin/ 1. Ist das nicht reichlich Overhead? 2. Wie macht tar das eigentlich? Kann man das nicht direkt selber machen? Ach ja. Tschüß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Mon, 10 Feb 2003 at 23:29 (+0100), Jörg Roßdeutscher wrote:
Moin,
Am Mon, 2003-02-10 um 12.57 schrieb David Haller:
On Mon, 10 Feb 2003, Jan Trippler wrote:
Ah ja - dann bleibt wohl nur Archive::Tar: http://search.cpan.org/author/KANE/Archive-Tar-0.23/lib/Archive/Tar.pm
Jup.
Jungens, helft doch mal 'nem alten Mann beim Denken.
Oh, hat Dich der letzte suse-hh-Abend so altern lassen? Oder eher das Warten auf den nächsten? *scnr*
Ich sehe da Methoden zum ein- und auspacken von tar-Archiven, aber nicht den segensbringenden cp-Ersatz.
Ich nehme mal an, daß einer dieser Befehle, wenn ich morgen nicht-müde nochmal draufgucke, in der Lage ist, ähnlich wie tar eine Datei mitsamt ihrer stati durchzuschieben wie tar -c dies_hier/ | tar -x dahin/
Ich habe nicht reingeguckt, nur danach gesucht ;-)
1. Ist das nicht reichlich Overhead?
Jupp, sehe ich auch so.
2. Wie macht tar das eigentlich? Kann man das nicht direkt selber machen?
Ich für meinen Teil würde es selbst in die Hand nehmen (mit dem touch-Paket ist ja auch die Möglichkeit gegeben, das Änderungsdatum zu manipulieren): Also eine Funktion bauen, die (rekursiv?) ein Verzeichnis abklappert (perldoc -f opendir|readdir|closedir), die interessierenden Dateien herauspickt, mtime liest (perldoc File::Stat), liest (@in = <IN>;), schreibt (print OUT @in;) und anschliessend mtime zurücksetzt. Sach Bescheid (PM), wenn Du Hilfe brauchst. Jan
Hallo, On Tue, 11 Feb 2003, Jan Trippler wrote:
On Mon, 10 Feb 2003 at 23:29 (+0100), Jörg Roßdeutscher wrote:
Jungens, helft doch mal 'nem alten Mann beim Denken.
Oh, hat Dich der letzte suse-hh-Abend so altern lassen? Oder eher ^^ Hambuerch? das Warten auf den nächsten? *scnr*
[..]
Ich für meinen Teil würde es selbst in die Hand nehmen (mit dem touch-Paket ist ja auch die Möglichkeit gegeben, das Änderungsdatum zu manipulieren): Also eine Funktion bauen, die (rekursiv?) ein Verzeichnis abklappert (perldoc -f opendir|readdir|closedir), die interessierenden Dateien herauspickt, mtime liest (perldoc File::Stat), liest (@in = <IN>;), schreibt (print OUT @in;) und anschliessend mtime zurücksetzt.
Sach Bescheid (PM), wenn Du Hilfe brauchst.
Noe, hier, bitte. Ist sowieso OnT. -dnh -- Die Netiquette ist (lediglich) eine FAQ zu der Frage "Warum sind die anderen so genervt von mir und nennen mich immer PLONK?". [Oliver Gassner in dsn]
On Die, 11 Feb 2003 at 04:17 (+0100), David Haller wrote:
On Tue, 11 Feb 2003, Jan Trippler wrote:
On Mon, 10 Feb 2003 at 23:29 (+0100), Jörg Roßdeutscher wrote:
Jungens, helft doch mal 'nem alten Mann beim Denken.
Oh, hat Dich der letzte suse-hh-Abend so altern lassen? Oder eher ^^ Hambuerch?
Jau. [...]
Sach Bescheid (PM), wenn Du Hilfe brauchst.
Noe, hier, bitte. Ist sowieso OnT.
Auch gut. Jan
So, Moin erstma, Am Die, 2003-02-11 um 04.17 schrieb David Haller:
On Tue, 11 Feb 2003, Jan Trippler wrote:
On Mon, 10 Feb 2003 at 23:29 (+0100), Jörg Roßdeutscher wrote:
Jungens, helft doch mal 'nem alten Mann beim Denken.
Oh, hat Dich der letzte suse-hh-Abend so altern lassen? Oder eher ^^ Hambuerch? das Warten auf den nächsten? *scnr*
Ne, der Umstieg auf Debian. :-)
Ich für meinen Teil würde es selbst in die Hand nehmen (mit dem touch-Paket ist ja auch die Möglichkeit gegeben, das Änderungsdatum zu manipulieren):
Jepp, das sieht gut aus.
Also eine Funktion bauen, die (rekursiv?) ein
Verzeichnis abklappert (perldoc -f opendir|readdir|closedir), die interessierenden Dateien herauspickt,
Nicht nötig, alles schon drin, um nur Fontfiles aus den Verzeichnissen rauszugraben.
mtime liest (perldoc
File::Stat), liest (@in = <IN>;), schreibt (print OUT @in;) und anschliessend mtime zurücksetzt.
Jepp, und da mit ist das Puzzle komplett. Nicht mehr vorm Release, aber auf jeden Fall in die ToDo-Liste. Danke!
Sach Bescheid (PM), wenn Du Hilfe brauchst.
Noe, hier, bitte. Ist sowieso OnT.
Genau. Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
Hallo, On Sat, 08 Feb 2003, Bernhard Walle wrote: [cp -a unportabel]
ueber tar nachzubilden. Ich weiss die entsprechenden Parameter nicht auswendig, vielleicht lesen hier irgendwelche Unix-Administratoren mit. Irgendwie habe ich im Hinterkopf, dass man sowas ueber tar-Pipes machen kann (mit Beibehaltung aller Attribute). Dass der Befehl umstaendlich ist kann Dir ja egal sein, Du musst ihn ja nicht auswendig koennen.
Unix-Admin bin ich zwar nicht, hab's aber oft verwendet und noch oefter hergebetet: cd Quelle; tar cp --atime-preserve | (cd Ziel; tar xp --atime-preserve) (hab ich erst neulich wieder verwendet, als ich die letzte Reiserfs-Partition auf ext3 migriert habe -- und ja, das war '/var' wo die atime relevant ist ;) Achso, via 'tar -C Quelle ... | (tar -C Ziel ... ) geht's evtl. auch. Inwieweit das alles portabel ist weiss ich aber leider nicht. Ralf? -dnh --
Was ist schon sicher auf dieser Welt? Das ich _nicht_ Bernd bin. Denn wenn ich Bernd wäre, würde ich existieren, und das ist ja bekanntlich nicht der Fall, da ich Volker bin. [Volker in suse-talk]
On Sun, 09 Feb 2003 at 02:00 (+0100), David Haller wrote:
On Sat, 08 Feb 2003, Bernhard Walle wrote: [cp -a unportabel]
ueber tar nachzubilden. Ich weiss die entsprechenden Parameter nicht auswendig, vielleicht lesen hier irgendwelche Unix-Administratoren mit. Irgendwie habe ich im Hinterkopf, dass man sowas ueber tar-Pipes machen kann (mit Beibehaltung aller Attribute). Dass der Befehl umstaendlich ist kann Dir ja egal sein, Du musst ihn ja nicht auswendig koennen.
Unix-Admin bin ich zwar nicht, hab's aber oft verwendet und noch oefter hergebetet:
cd Quelle; tar cp --atime-preserve | (cd Ziel; tar xp --atime-preserve)
(hab ich erst neulich wieder verwendet, als ich die letzte Reiserfs-Partition auf ext3 migriert habe -- und ja, das war '/var' wo die atime relevant ist ;)
Ich habe damals tar -cSp --numeric-owner -f - . | ( cd /NEW && tar xSpvf - ) verwendet, steht in der SuSE-Supportdatenbank.
Achso, via 'tar -C Quelle ... | (tar -C Ziel ... ) geht's evtl. auch.
Inwieweit das alles portabel ist weiss ich aber leider nicht. Ralf?
Unter HP_UX gibt's diese Option. Gruß, Bernhard -- Was wir wissen, ist ein Tropfen; was wir nicht wissen, ein Ozean. -- Isaac Newton
Moin, Am Sam, 2003-02-08 um 15.25 schrieb Bernhard Walle:
On Sat, 08 Feb 2003 at 14:36 (+0100), Ratti wrote:
Am Sam, 2003-02-08 um 11.08 schrieb Bernhard Walle: Ja, und genau das meinte ich mit "Windows kann kein "/" im Dateinamen. "Unnötige Probleme" heisst ja, das irgendwo irgendwas nciht funktioniert. Daher machen die Fontlinge beim generieren von Dateinamen ein s/\W/_/gs;
Nein, es heisst, dass es _unter_bestimmten_Umstaenden_ nicht funktioniert. Natuerlich ist es sinnvoll solche Zeichen mit einem Unterstrich zu escapen.
"Funktioniert meistens" ist "Funktioniert nicht". Was nützt es mir, wenn eine Struktur solange funktioniert - bis ich die Daten auf CD brennen will. Wenn die Software mich nicht ins Ziel bringen kann, ist es egal, wo ich scheitere. (Es ist eindeutig ein Defizit der deutschen Sprache, daß es den Begriff "gescheitert werde" nicht gibt. :-) )
`cp -a $src $dest`;
Ist -a nicht eine GNU-Erweiterung? Bin mir aber nicht sicher.
Tja. Ich weiss es nicht. Aber was soll ich machen? Wenn andere das Feature nicht anbieten kann ich a) Für alle das Feature auch nicht anbieten b) Nur den OSsen eine lange Nase ziehen, die das Feature nicht haben.
Ich bevorzuge b).
Man kann ja zunaechst pruefen, ob es sich um eine GNU-Umgebung handelt und dann die ensprechenden Befehle setzen, d. h. wenn das OS das Feature bietet, dann nimmt man -a her, ansonsten laesst man es sein. Immer noch besser als gar nichts. Ansonsten wuerde sich anbieten, das Ganze ueber tar nachzubilden. Ich weiss die entsprechenden Parameter nicht
tar ist eine hübsche Idee. Oder man schreibt einfach "Gnu cp" in die Requirements.
Gerade bei Fonts ist es so, daß häufig irgendwelche Leute irgendwo einen Fonteditor ausgraben und einen Haufen Quatsch anrichten. Dieser Quatsch wandert dann zusammen mit irgendwelchen Jobs in den eigenen Datenbestand. Du hast dann 12 Helveticas. Davon sind 2 einfach kaputt, drei weitere haben keine deutschen Umlaute, und eine hat Umlaute auf dem Bildschirm - aber nciht im Druck. Gargl.
-> kaputte Schriften einfach loeschen. ;-)
Das geht leider nicht. Wenn in einem Font die Verwendung des "§"-Zeichens das RIP zum Absturz bringt, aber ein 400seitiger Katalog damit gesetzt wurde, dann kann man den nicht mal eben umbauen. Es ist ein Irrtum, zu glauben, man würde den Mist schon aufräumen, wenn der verflixte Job nur endlich durch wäre. Die Neuauflage ist schon in Arbeit - mit dem gleichen Font. :-)))
In einer reinen Linux-Umgebung würden sich die Freaks wohl MD5-Checksummen zuwerfen, um festzustellen, wer welche hat. In einer
Ich nehme oft die Dateigroesse als Vergleichskriterium.
Weil dein Linux-System nicht sowas sagt wie "128 KB", sondern "112.143.222 Bytes". Mac-Rechner zeigen als Dateilänge den Clusterverbrauch auf der Platte an, sprich: Schritte von z.B. 16 KB. Man kann die Länge zwar in einem Infodialog nachgucken... Naja. Kann. Gruß, Ratti -- fontlinge Font management for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Son, 09 Feb 2003 at 22:36 (+0100), Jörg Roßdeutscher wrote: [...]
"Funktioniert meistens" ist "Funktioniert nicht".
Nein, nicht unbedingt. Kann auch heissen: *Funktioniert in den Varianten, in denen es gebraucht wird*, dann wird es zu *funktioniert*.
Was nützt es mir, wenn eine Struktur solange funktioniert - bis ich die Daten auf CD brennen will. Wenn die Software mich nicht ins Ziel bringen kann, ist es egal, wo ich scheitere. (Es ist eindeutig ein Defizit der deutschen Sprache, daß es den Begriff "gescheitert werde" nicht gibt. :-) )
Hilft Dir *scheitern werde* oder *gescheitert sein werde* weiter? SCNR [...]
tar ist eine hübsche Idee. Oder man schreibt einfach "Gnu cp" in die Requirements.
Wie wäre es mit cpio [-p]? Das ist IMHO hochgradig portabel. Jan
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]
Moin, Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz:
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 ;-)
Naja, "fest" ist bei OpenSource alles, was nicht lose ist... :-) Du hast Recht, und genau deswegen habe ich das bei mir wieder gekickt. Wenn ich die Diskussion richtig verstehe, drängt sich mir auf, daß es keinen "sauberen" Weg gibt, $UserDir automatisch zu ermitteln? (Beziehungsweise: Jeder Automatismus würde so oft fehlschlagen, daß man häufiger richtig liegt, wenn man ~/public_html einfach vorraussetzt?) Wäre es da nicht das sinnvollste, ~/public_html auf Existenz zu überprüfen? Wenn da, dann nehmen, wenn nicht da, explizite Angabe des Pfades fordern und exit? Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-) Gruß, Ratti -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Thu, 06 Feb 2003 at 21:08 (+0100), Ratti wrote:
Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-)
Und dabei blinkt der Standardcursor vom xterm doch gar nicht *kopfschuettel* Gruß, Bernhard -- "Never do today what you can postpone and do tomorrow." -- David Faure
Moin, Am Don, 2003-02-06 um 21.17 schrieb Bernhard Walle:
On Thu, 06 Feb 2003 at 21:08 (+0100), Ratti wrote:
Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-)
Und dabei blinkt der Standardcursor vom xterm doch gar nicht *kopfschuettel*
Quatsch. Guck nochmal genau hin... ach, du mußt natürlich eine Designerbrille tragen! Von Gucci! Dann siehst du nämlich ganz genau, daß der Cursor blinkt, und er hat feuerrote tote Augen, mit denen er dich anstarrt und brüllt: ".. UND WENN DU DICH VERTIPPST, DANN FRESSE ICH DICH MITSAMT DEINEM DEINEN MAUSZEIGER!!!!" Sowas macht der. Ui... total fies... Gruß, Ratti (Der sich da voll auskennt) -- fontlinge Fontmanagement for Linux http://www.gesindel.de Schriftenverwaltung fuer Linux
On Sat, 08 Feb 2003 at 10:28 (+0100), Ratti wrote:
Am Don, 2003-02-06 um 21.17 schrieb Bernhard Walle:
On Thu, 06 Feb 2003 at 21:08 (+0100), Ratti wrote:
Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-)
Und dabei blinkt der Standardcursor vom xterm doch gar nicht *kopfschuettel*
Quatsch.
Guck nochmal genau hin... ach, du mußt natürlich eine Designerbrille tragen! Von Gucci! Dann siehst du nämlich ganz genau, daß der Cursor blinkt, und er hat feuerrote tote Augen, mit denen er dich anstarrt und brüllt: ".. UND WENN DU DICH VERTIPPST, DANN FRESSE ICH DICH MITSAMT DEINEM DEINEN MAUSZEIGER!!!!"
Sowas macht der. Ui... total fies...
LOL. Kann es sein dass Du den Cursor *zu lange* angeschaut hast ohne was einzutippen und der Cursor einfach sauer wurde? BTW: Strg+Mittelklick im xterm bringt ein Menue, indem Du tatsaechlich einen Blinkecursor einstellen kannst. Gruß, Bernhard -- Als ich klein war, glaubte ich, Geld sei das wichtigste im Leben. Heute, da ich alt bin, weiß ich: Es stimmt. -- Oscar Wilde
Hallo, On Thu, 06 Feb 2003, Jörg Roßdeutscher wrote:
Am Mit, 2003-02-05 um 23.45 schrieb Christian Boltz:
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 ;-)
Naja, "fest" ist bei OpenSource alles, was nicht lose ist... :-)
*g*
Wenn ich die Diskussion richtig verstehe, drängt sich mir auf, daß es keinen "sauberen" Weg gibt, $UserDir automatisch zu ermitteln?
Stimmt. Leider. Selbst mit apxs (das bei mir im apache-rpm war) nicht.
(Beziehungsweise: Jeder Automatismus würde so oft fehlschlagen, daß man häufiger richtig liegt, wenn man ~/public_html einfach vorraussetzt?)
Scheint so.
Wäre es da nicht das sinnvollste, ~/public_html auf Existenz zu überprüfen?
Hm. Existenz reicht evtl. nicht, da das AFAIR SuSE z.B. automatisch mit irgendnem RPM mit anlegt (skel?)... Vielleicht, ob ne Datei unterhalb davon existiert oder so... Aber "ja".
Wenn da, dann nehmen, wenn nicht da, explizite Angabe des Pfades fordern und exit?
Ok. Ich habe Christian grad nen (moeglichen kompletten) Umbau der Installprozedur vorgeschlagen bzw. die Moeglichkeiten angedeutet, der sich aus dem Verbessern[0] des Makefile.PL von fontlinge::Subs[1] quasi "automatisch" ergibt. Und das bietet dann z.B. bequeme "Abfragen"... Die Grenze zwischen dem Bisherigem und dem "Umbau" kann man aber fast an jeder Stelle ziehen! Weiteres sollten wir per PM klaeren.
Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-)
*g* gesiggt. Hm. dialog/kdialog/gdialog? Ah, ne, koennte man per perl/Tk oder perl/Gtk machen (Gtk wird ja eh benoetigt) ;) Halte ich aber fuer overkill... -dnh [0] so dass es halbwegs CPAN "konform" ist, und z.B. auch die "requires" ueberprueft [1] Das ich gleich in Fontlinge::Subs umbenannt habe, naeheres folgt per PM/auf fontlinge-devel -- 54: Jetzt mit neuem, umfangreichem Softwarepaket. Treiber liegt bei. (Kristian Köhntopp)
Hallo David, hallo Ratti, hallo Leute, Am Freitag, 7. Februar 2003 01:59 schrieb David Haller:
On Thu, 06 Feb 2003, Jörg Roßdeutscher wrote:
Wäre es da nicht das sinnvollste, ~/public_html auf Existenz zu überprüfen?
Hm. Existenz reicht evtl. nicht, da das AFAIR SuSE z.B. automatisch mit irgendnem RPM mit anlegt (skel?)... Vielleicht, ob ne Datei unterhalb davon existiert oder so...
Naja, jetzt übertreibst Du ein wenig ;-) Was ist, wenn jemand einfach noch nix in public_html abgelegt hat? IMHO reicht ein test -d ~/public_html || \ read -p "Where is your Apache UserDir?" -e userdir
Wenn da, dann nehmen, wenn nicht da, explizite Angabe des Pfades fordern und exit?
So ähnlich, siehe oben.
Die fontlinge sollen ... ähm... wie soll ich es sagen... eher visuell als technisch orientierten Menschen bei der Verwaltung ihrer Fonts helfen. Wenn die 'ne Kommandozeilenoption eintippen müssen, laufen sie schreiend weg und verstecken sich zitternd hinter ihrem Mac, bis der böse, böse Blinkecursor weggeht. ;-)
*ROTFL*
*g* gesiggt.
Du auch? ;-)
Hm. dialog/kdialog/gdialog? Ah, ne, koennte man per perl/Tk oder perl/Gtk machen (Gtk wird ja eh benoetigt) ;) Halte ich aber fuer overkill...
Jepp, "read -e" reicht IMHO ;-) Gruß Christian Boltz --
[zerkratzte CD mit Zahnpasta polieren] Und der Bonus dabei: Deine CD duftet angenehm nach Minze... ;-)) ...und die CD ist zukünftig gegen Karies und Paradonthose geschützt [> Martin Kropfinger und Lars Zimmermann in suse-linux]
Hallo, [f'up2poster] On Fri, 07 Feb 2003, Christian Boltz wrote:
Am Freitag, 7. Februar 2003 01:59 schrieb David Haller:
On Thu, 06 Feb 2003, Jörg Roßdeutscher wrote:
Wäre es da nicht das sinnvollste, ~/public_html auf Existenz zu überprüfen?
Hm. Existenz reicht evtl. nicht, da das AFAIR SuSE z.B. automatisch mit irgendnem RPM mit anlegt (skel?)... Vielleicht, ob ne Datei unterhalb davon existiert oder so...
Naja, jetzt übertreibst Du ein wenig ;-) Was ist, wenn jemand einfach noch nix in public_html abgelegt hat?
IMHO reicht ein test -d ~/public_html || \ read -p "Where is your Apache UserDir?" -e userdir
Jo. Erstmal auf jedenfall.
*g* gesiggt.
Du auch? ;-)
Jep.
Hm. dialog/kdialog/gdialog? Ah, ne, koennte man per perl/Tk oder perl/Gtk machen (Gtk wird ja eh benoetigt) ;) Halte ich aber fuer overkill...
Jepp, "read -e" reicht IMHO ;-)
Jo. Oder, falls(!) aus nem "Makefile.PL" heraus, via "prompt()" ;) -dnh -- Schliesslich haben wir unsere Gehirne ja nicht aus dem Restpostenverkauf bekommen. [WoKo in dag°]
participants (7)
-
Bernhard Walle -
Christian Boltz -
David Haller -
Jan.Trippler＠t-online.de -
Jörg Roßdeutscher -
Michael Matz -
Ralf Corsepius