autogen.sh oder buildconf
Holger Schopohl
Hi,
ich habe keine Hinweise dazu gefunden, ob es besser ist dieses typische
#!/bin/sh
aclocal
automake
autoconf
als
buildconf (wie in Apache, PHP, cURL)
oder
autogen.sh
zu benennen.
Gibt es dazu 'Konventionen', Hinweise was wohl derzeit besser (moderner)
ist ?
Grüße,
Holger
Enrico Scholz
> ich habe keine Hinweise dazu gefunden, ob es besser ist dieses typische
> #!/bin/sh
> aclocal
> automake
> autoconf
Braucht kein Mensch. Nimm 'autoreconf'; das ist bei 'autoconf' schon
dabei und macht das, was Du mit Deinem Skript erreichen willst.
Enrico
Martin Dickopp
> ich habe keine Hinweise dazu gefunden, ob es besser ist dieses typische
> #!/bin/sh
> aclocal
> automake
> autoconf
>
> als
>
> buildconf (wie in Apache, PHP, cURL)
> oder
> autogen.sh
>
> zu benennen.
Bei mir heißt dieses Skript, das natürlich nur in der CVS-Version,
nicht aber in den Releases vorhanden ist, `bootstrap-from-cvs'. Es hat
folgenden Inhalt:
#! /bin/sh
set -e
if automake --version | sed 1q | egrep '\<1\.7$' > /dev/null; then :; else
echo "$0: automake version 1.7 is required to build the CVS version of this package" >&2
exit 1
fi
if autoconf --version | sed 1q | egrep '\<2\.54$' > /dev/null; then :; else
echo "$0: autoconf version 2.54 is required to build the CVS version of this package" >&2
exit 1
fi
aclocal
autoheader
automake -a
autoconf
echo
echo "**** The CVS version of this package has been prepared for building."
echo "**** Next, type \`./configure' to configure it."
echo
exit 0
> Gibt es dazu 'Konventionen', Hinweise was wohl derzeit besser
> (moderner) ist ?
^
((Bitte nicht plenken.))
Mir sind dazu keine Konventionen bekannt. Wer aber nicht in der Lage
ist, das Skript zu finden, egal wie es heißt, sollte IMHO gar nicht
erst versuchen, die CVS-Version eines Packages zu bauen.
Martin
Gunnar Ritter
> egrep '\<1\.7$'
^^
Proprietäre RE. \< und \> können portabel nur in ex und vi
verwendet werden.
Gunnar
Martin Dickopp
> Martin Dickopp <firefl...@gmx.net> wrote:
>
>> egrep '\<1\.7$'
> ^^
>
> Proprietäre RE. \< und \> können portabel nur in ex und vi
> verwendet werden.
Recht hast Du. Danke!
Ich hatte angenommen, \< und \> seien normierter Bestandteil der
Extended Regular Expression. Ein Blick in IEEE Std 1003.1-2001 hat mir
jedoch gezeigt, daß ich mich geirrt habe. Werde meinen Code umgehend
fixen...
Martin
Holger Schopohl
> Ich hatte angenommen, \< und \> seien normierter Bestandteil der
> Extended Regular Expression. Ein Blick in IEEE Std 1003.1-2001 hat mir
> jedoch gezeigt, daß ich mich geirrt habe. Werde meinen Code umgehend
> fixen...
Und bitte, wenn Du kannst, auch hier gleich posten.
Wäre sehr dankbar.
Grüße,
Holger
Gunnar Ritter
> Und bitte, wenn Du kannst, auch hier gleich posten.
In der 99-prozentigen Annahme, daß niemand so blöd war, Spaces
in die Versionsnummer zu bauen, und daß sie immer hinten steht:
if test "`automake --version | sed 's/.* //; q'`" != 1.7
Allerdings finde ich die ganze Aktion etwas zweifelhaft. Warum
laßt ihr die Tools nicht einfach laufen und dann fehlschlagen,
_wenn_ sie fehlschlagen? So macht ihr z. B. den Leuten unnötigen
Ärger, die eine neuere Version haben - die eventuell problemlos
durchlaufen würde, aber die Chance dazu gar nicht erst bekommt.
Gunnar
Enrico Scholz
> Holger Schopohl <poi...@gmx.de> wrote:
> ... `bootstrap-from-cvs' ...
>
> #! /bin/sh
> set -e
> if automake --version | sed 1q | egrep '\<1\.7$' > /dev/null; then :; else
> echo "$0: automake version 1.7 is required to build the CVS version of this package" >&2
> exit 1
> fi
Was soll dieser Test? Sowohl automake als auch autoconf kann innerhalb
des configure.ac mitgeteilt werden, welche Version des jeweiligen Tools
benoetigt wird. Die Zeit die Du fuer's Schreiben fehlerhafter Wrapper
aufwendest, solltest Du lieber ins Lesen der Dokumentation investieren.
Enrico
Martin Dickopp
> Allerdings finde ich die ganze Aktion etwas zweifelhaft. Warum laßt
> ihr die Tools nicht einfach laufen und dann fehlschlagen, _wenn_ sie
> fehlschlagen? So macht ihr z. B. den Leuten unnötigen Ärger, die
> eine neuere Version haben - die eventuell problemlos durchlaufen
> würde, aber die Chance dazu gar nicht erst bekommt.
Wenn die neuere Version allerdings nicht problemlos durchläuft,
sondern ein configure-Skript erzeugt, daß sich anders verhält, als
ich das getestet habe, wird es schwierig, eventuelle Fehler zu
diagnostizieren.
Kurz gesagt: Es würde meine Möglichkeiten übersteigen, für alle
Versionskombinationen von Automake, Autoconf und meiner Software
Support zu leisten. Darum leiste ich in der Tat nur dann kostenlosen
Support für CVS-Versionen meiner Software, wenn ich die Benutzung ganz
spezifischer Versionen von Automake und Autoconf "vorschreiben" kann.
Martin
Gunnar Ritter
> Kurz gesagt: Es würde meine Möglichkeiten übersteigen, für alle
> Versionskombinationen von Automake, Autoconf und meiner Software
> Support zu leisten. Darum leiste ich in der Tat nur dann kostenlosen
> Support für CVS-Versionen meiner Software, wenn ich die Benutzung ganz
> spezifischer Versionen von Automake und Autoconf "vorschreiben" kann.
Kein Wunder, daß Du ein Problem mit «Support» hast, wenn Du
potentielle Helfer schon mit den Buildskripten vergraulst.
Überhaupt, willst Du uns hier eigentlich verarschen? Dein
Projekt besteht abzüglich reinen Daten und GNU-Glue aus etwa
2000 Zeilen Code ohne irgendeine ernsthafte Abhängigkeit von
irgendeinem System. Unter diesen Umständen genügt ein simples
Makefile mit -ljpeg und drei Checks auf Header drin, und Du
bist alle autobloat-Probleme los.
Gunnar
Martin Dickopp
> Überhaupt, willst Du uns hier eigentlich verarschen?
Tut mir leid, wenn Du Dich verarscht fühlst, aber ich habe Dir
keinerlei Veranlassung dazu gegeben.
Der OP hat um eine Meinung gebeten, wie er ein bestimmtes Skript
nennen soll, und ich habe ihm meine Meinung dazu mitgeteilt. Was
genau paßt Dir daran jetzt nicht?
> Dein Projekt besteht abzüglich reinen Daten und GNU-Glue aus etwa
> 2000 Zeilen Code ohne irgendeine ernsthafte Abhängigkeit von
> irgendeinem System.
Na und?
> Unter diesen Umständen genügt ein simples Makefile mit -ljpeg und
> drei Checks auf Header drin, und Du bist alle autobloat-Probleme
> los.
Ich nehme zur Kenntnis, daß Du anscheinend der Meinung bist, man solle
Automake und Autoconf nur bei großen Projekten verwenden. Ich bin
dieser Meinung allerdings nicht, selbst dann nicht, wenn Du Dich durch
meine abweichende Meinung verarscht fühlst.
Martin
PS: fup2poster
Gunnar Ritter
>> Unter diesen Umständen genügt ein simples Makefile mit -ljpeg und
>> drei Checks auf Header drin, und Du bist alle autobloat-Probleme
>> los.
> Ich nehme zur Kenntnis, daß Du anscheinend der Meinung bist, man solle
> Automake und Autoconf nur bei großen Projekten verwenden.
Nein! Man muß es nicht mal bei großen Projekten verwenden. Man
soll es nur dann verwenden, wenn man der Buildprozess so viele
und komplexe Systemabhängigkeiten aufweist, daß es sich lohnt.
Sonst fügt man nur Bloat in den Buildprozeß ein, den man dann
extra zu warten hat. Man macht sich völlig ohne Not von einem
weiteren Tool abhängig, das gepflegt werden will. Wie Du ja
durch Deine Vorsicht vor Änderungen in künfigen autobloat-
Versionen hier prima demonstriert hast.
Und automake sollte man besser überhaupt nicht verwenden.
> Ich bin dieser Meinung allerdings nicht,
Nein, natürlich nicht. Du wirst den ganzen Kram schon deshalb
nicht wegwerfen, weil Du - überflüssigerweise - viel Zeit darauf
aufgewendet hast und man sich einfach besser fühlt, wenn man
sich vorgaukeln kann, es sei sinnvoller Code herausgekommen.
Ist es aber nicht. Im Gegenteil, Du hast Dir da einfach einen
riesigen Klotz ans Bein gehängt.
Aber Du darfst natürlich gerne weiter so rumlaufen, wenn es Dir
Spaß macht. Bei mir darf jeder machen, was er will.
> PS: fup2poster
Wenn ich das Bedürfnis habe, Dir Mails zu schreiben, kann ich
das schon prima alleine. Und daß Du außer «ich bin der Meinung»
keine Argumente hast, ist schließlich nicht meine Schuld.
Gunnar
Gunnar Ritter
>> Unter diesen Umständen genügt ein simples Makefile mit -ljpeg und
>> drei Checks auf Header drin, und Du bist alle autobloat-Probleme
>> los.
> Ich nehme zur Kenntnis, daß Du anscheinend der Meinung bist, man solle
> Automake und Autoconf nur bei großen Projekten verwenden.
Nein! Man muß es nicht mal bei großen Projekten verwenden. Man
soll es nur dann verwenden, wenn man der Buildprozess so viele
und komplexe Systemabhängigkeiten aufweist, daß es sich lohnt.
Sonst fügt man nur Bloat in den Buildprozeß ein, den man dann
extra zu warten hat. Man macht sich völlig ohne Not von einem
weiteren Tool abhängig, das gepflegt werden will. Wie Du ja
durch Deine Vorsicht vor Änderungen in künfigen autobloat-
Versionen hier prima demonstriert hast.
Und automake sollte man besser überhaupt nicht verwenden.
> Ich bin dieser Meinung allerdings nicht,
Nein, natürlich nicht. Du wirst den ganzen Kram schon deshalb
nicht wegwerfen, weil Du - überflüssigerweise - viel Zeit darauf
aufgewendet hast und man sich einfach besser fühlt, wenn man
sich vorgaukeln kann, es sei sinnvoller Code herausgekommen.
Ist es aber nicht. Im Gegenteil, Du hast Dir da einfach einen
riesigen Klotz ans Bein gehängt.
Aber Du darfst natürlich gerne weiter so rumlaufen, wenn es Dir
Spaß macht. Bei mir darf jeder machen, was er will.
> PS: fup2poster
Wenn ich das Bedürfnis habe, Dir Mails zu schreiben, kann ich
das schon prima alleine. Und daß Du außer «ich bin der Meinung»
keine Argumente anführst, ist schließlich nicht meine Schuld.
Gunnar
Felix von Leitner
> > Und bitte, wenn Du kannst, auch hier gleich posten.
> In der 99-prozentigen Annahme, daß niemand so blöd war, Spaces
> in die Versionsnummer zu bauen, und daß sie immer hinten steht:
> if test "`automake --version | sed 's/.* //; q'`" != 1.7
Genau das war in autogen.sh bei gtk und gimp drin und fiel bei
Beta-Versionen von auto* regelmäßig voll auf die Fresse.
Es gibt so gut wie keinen dummen Fehler, den nicht schon mal jemand
gemacht hat. Aber gtk ist eh total für den Fuß. Es gibt eine wunderbar
portable und cross-compiler-fähige autoconf-Lösung, um die Größe eines
Typs festzustellen. gtk definiert sich ein eigenes Makro, das auf
printf(sizeof()) hinausläuft. Ist natürlich nicht cross-compiler-fähig.
Man kann gar nicht so viel fressen, wie man kotzen möchte.
> Allerdings finde ich die ganze Aktion etwas zweifelhaft. Warum
> laßt ihr die Tools nicht einfach laufen und dann fehlschlagen,
> _wenn_ sie fehlschlagen? So macht ihr z. B. den Leuten unnötigen
> Ärger, die eine neuere Version haben - die eventuell problemlos
> durchlaufen würde, aber die Chance dazu gar nicht erst bekommt.
Das ist ja mit Abstand mein "liebstes" Problem. Leute, die in configure
Fehler abfangen, die ihnen noch nie begegnet sind, deren Auswirkungen
ihnen nicht klar sind, und für die es keine sinnvolle Reaktion gibt.
Wenn ich Zugang zu orbitalen Ionenkanonen hätte, hierfür würde ich sie
einsetzen. 70% der ärgerlichen configure-Fummeleien fallen in diese
Kategorie.
Leute: tut es einfach _nicht_. Nicht. Finger weg. Wenn ihr keine
Ahnung habt, macht es einfach nicht. Ganz einfach. Niemand zwingt
euch, autoconf zu benutzen. Wenn ihr es nicht könnt, tut es nicht.
Ist ja wohl nicht so schwierig, oder? Na also.
*fluch*
Felix
Felix von Leitner
> Wenn die neuere Version allerdings nicht problemlos durchläuft,
> sondern ein configure-Skript erzeugt, daß sich anders verhält, als
> ich das getestet habe, wird es schwierig, eventuelle Fehler zu
> diagnostizieren.
Nein, wieso?
Der Fehler ist, daß du Tools einsetzt, die du nicht beherrscht.
Ganz eindeutig, und ganz ohne Debuggen feststellbar.
> Kurz gesagt: Es würde meine Möglichkeiten übersteigen, für alle
> Versionskombinationen von Automake, Autoconf und meiner Software
> Support zu leisten.
Warum auch. auto*-Software liefert man mit fertigen configure-Scripten
aus und ist fertig. Das weiß jeder, der schon mehr als ein halbes
Projekt mit autoconf und Freunden gemacht hat. Sobald der User bei sich
autoconf aufruft, gibt es Ärger.
Wieso setzt du Software ein, die du nicht beherrschst?
Warum machst du nicht lieber Visual Basic unter Windoze, das scheint
deinen Fähigkeiten angemessener zu sein.
Felix
Felix von Leitner
> Automake und Autoconf nur bei großen Projekten verwenden.
Automake sollte man gar nicht einsetzen, und autoconf sollte man genau
dann einsetzen, wenn man sich gut damit auskennt. Es gibt auf der Welt
keine 100 Leute, die sich gut mit autoconf auskennen. Der Rest sollte
lieber Windoze machen oder sich erschießen als Müllware zu produzieren.
Rainer Weikusat
> Ich nehme zur Kenntnis, daß Du anscheinend der Meinung bist, man solle
> Automake und Autoconf nur bei großen Projekten verwenden. Ich bin
> dieser Meinung allerdings nicht,
Glaubs' einfach, Martin. Falls ich $whatever hier übersetzten müssen
sollte, wird mich Deine Versionsabfrage genau solange ärgern, bis ich
sie gefunden und entfernt habe. Und aus configure.in & friends
irgendwelche Idiotien zu entsorgen, ist wirklich *kein* Spaß.
Wenn wir das mal weiterspinnen, würde ich Dir für den Fall
(hypothetischer) build-Probleme mit späteren/ anderen Versionen
wahrscheinlich patches zukommen lassen, allerdings nicht, falls Du
mich auch noch aktiv daran zu hindern versuchst, das Programm zu
kompilieren: Es ist Zeitverschwendung, mit Leuten zu reden, die einen
ohnehin für blöd halten, denn sobald die etwas hören, was sie nicht
ohne nachzudenken verstehen, nehmen sie idR an, es 'mit einem Verrückten'
zu tun zu haben (Dauerbrenner seit zwanzig Jahren).
Das meiste, was bei autoconf 'von alleine' geht, kann man sich auf
einem aktuellen System schlicht ersparen, und falls jemand da mal 3-70
Zeilen Quellcode für eine Portierung verbrechen muß, wird das sehr
viel angenehmer, falls man sich von den Autotools-paperdocs fernhalten
kann. Die sind ohnehin bestenfalls halb dokumentiert und davon
größtenteils noch, was alles nicht funktioniert.
Martin Dickopp
> auto*-Software liefert man mit fertigen configure-Scripten aus und
> ist fertig.
Schön, daß wir uns einig sind. Das mache ich selbstverständlich auch
so. :)
(Allerdings zähle ich "über CVS bereitstellen" nicht als
"ausliefern".)
> Wieso setzt du Software ein, die du nicht beherrschst?
Weil man nur dadurch etwas lernt. Oder setzt Du nur Software ein,
deren Beherrschung Dir bereits angeboren ist? ;)
(Damit meine ich übrigens nicht Automake und Autoconf. Ich setze aber
tatsächlich auch Software ein, die ich nicht beherrsche.)
> Warum machst du nicht lieber Visual Basic unter Windoze,
Weil es sich dabei um eine Sprache handelt, die nicht durch ein
unabhängiges Gremium normiert ist, die nur auf einer einzigen
Plattform läuft, und für die es keine nicht-proprietäre
Implementierung gibt.
Martin
Martin Dickopp
> Wenn wir das mal weiterspinnen, würde ich Dir für den Fall
> (hypothetischer) build-Probleme mit späteren/ anderen Versionen
> wahrscheinlich patches zukommen lassen,
Solche Patches wären selbstverständlich höchst willkommen. :)
> allerdings nicht, falls Du mich auch noch aktiv daran zu hindern
> versuchst, das Programm zu kompilieren: Es ist Zeitverschwendung,
> mit Leuten zu reden, die einen ohnehin für blöd halten,
Ich hatte bisher nicht den Eindruck, daß eine simple Versionsabfrage
in der CVS-Version so interpretiert wird. Ich nehme Deine Kritik aber
dankend an, und werde mein Skript überdenken.
Würdest Du bei einer Meldung der Art "Warning: The CVS version of this
package has only been tested with automake 1.7" (ohne, daß das Skript
an der Stelle abbricht) auch so empfinden, oder wäre das für Dich
akzeptabel?
Martin
Martin Dickopp
> Du wirst den ganzen Kram schon deshalb nicht wegwerfen, weil Du -
> überflüssigerweise - viel Zeit darauf aufgewendet hast und man sich
> einfach besser fühlt, wenn man sich vorgaukeln kann, es sei
> sinnvoller Code herausgekommen.
Falsch.
Ich werde "den ganzen Kram" weiterverwenden, weil es für mich ein-
facher ist, 6 Zeilen Makefile.am und unter 30 Zeilen configure.ac zu
pflegen, als ein configure-Skript und ein Makefile von Hand zu
erstellen und zu pflegen.
> Bei mir darf jeder machen, was er will.
Fein, dann darf ich also auch weiterhin meine Meinung zu Automake und
Autoconf in dieser Newsgroup verbreiten (als Antwort auf entsprechende
Fragen, versteht sich).
Martin
Gerd Knorr
> > drei Checks auf Header drin, und Du bist alle autobloat-Probleme
> > los.
>
> Ich nehme zur Kenntnis, daß Du anscheinend der Meinung bist, man solle
> Automake und Autoconf nur bei großen Projekten verwenden.
automake will man gar nicht verwenden. autoconf ist ganz nett, lohnt in
der Tat aber nur wenn man nicht-triviale checks braucht (was im übrigen
von der Größe des Projektes unabhänig ist). Einfache Sachen kann man
auch direkt im Makefile abfackeln (von webfsd, zwecks besserer
Übersichtlichkeit etwas zusammengestrichen):
==============================[ cut here ]==============================
# config
USE_SSL := auto
[ ... ]
# poor man's autoconf :-)
SYSTEM := $(shell uname -s | tr "A-Z" "a-z")
HAVE_SSL := $(shell test -f /usr/include/openssl/ssl.h && echo yes || echo no)
[ ... ]
# OpenSSL yes/no
ifeq ($(USE_SSL),auto)
USE_SSL := $(HAVE_SSL)
endif
ifeq ($(USE_SSL),yes)
CFLAGS += -DUSE_SSL=1
OBJS += ssl.o
LDLIBS += -lssl
endif
[ ... ]
$(TARGET): $(OBJS)
$(CC) $(CFLAGS) -o $@ $(OBJS) $(LDLIBS)
%.o : %.c
$(CC) $(CFLAGS) -Wp,-MD,.depend -c -o $@ $<
@sed -e "s|.*\.o:|$@::|" < .depend > .$*.dep && rm -f .depend
-include .*.dep
==============================[ cut here ]==============================
> Ich bin dieser Meinung allerdings nicht, selbst dann nicht, wenn Du
> Dich durch meine abweichende Meinung verarscht fühlst.
Ist mir doch egal was Du machst und welche Meinung Du hast. IMHO ist
der einfachste Weg die Probleme mit automake los zu werden automake
gar nicht erst zu verwenden. Wenn Du das anders siehst -- bitte. Du
must dann mit automake klar kommen, nicht ich.
> PS: fup2poster
Wieso das?
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
Felix von Leitner
> HAVE_SSL := $(shell test -f /usr/include/openssl/ssl.h && echo yes || echo no)
Das ist jetzt nicht dein Ernst, oder?
Du prüfst nicht mal den Default-Pfad der Standard-Installation?!
> > PS: fup2poster
> Wieso das?
Laß ihn doch. Vielleicht wird ihm langweilig und er geht.
Rainer Weikusat
> Würdest Du bei einer Meldung der Art "Warning: The CVS version of
> this package has only been tested with automake 1.7"
Warum schreibst Du nicht etwas in der Art von 'benötigt ..., getestet
mit Version ...' in ein Readme?
Martin Dickopp
> Ist mir doch egal was Du machst und welche Meinung Du hast.
Der OP hatte um eine Meinung gebeten, also habe ich eine solche
geäußert.
> Du must dann mit automake klar kommen, nicht ich.
Ich komme auch damit klar. Habe nie etwas anderes behauptet.
Martin
Martin Dickopp
Ja, ich gehe demnächst, da ich nicht den Eindruck habe, daß die
jetzige Diskussion dem OP noch irgendwie weiterhilft.
Martin
Martin Dickopp
Leider liest nicht jeder READMEs. Aber ich möchte natürlich anderer-
seits auch nicht gerade die User vergraulen, die potentiell Patches
beitragen würden. Insofern muß ich das genaue Vorgehen noch mal über-
denken.
Martin
Gunnar Ritter
> # poor man's autoconf :-)
> SYSTEM := $(shell uname -s | tr "A-Z" "a-z")
> HAVE_SSL := $(shell test -f /usr/include/openssl/ssl.h && echo yes || echo no)
Das hat aber gegenüber autoconf-Checks den handfesten Nachteil,
daß es nicht portabel ist. Ich mache bei einigen kleineren Sachen
sowas:
config.h:
-echo '/* Auto-generated by make. Do no edit! */' >config.h
-echo '#include <wchar.h>' >___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test -f ___build$$$$.o ; \
then echo '#include <wchar.h>' >>config.h ; \
echo '#define WCHARS' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
-echo '#include <wctype.h>' >___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test -f ___build$$$$.o ; \
then echo '#include <wctype.h>' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
-echo '#include <libgen.h>' >___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test -f ___build$$$$.o ; \
then echo '#include <libgen.h>' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
-echo '#include <sys/types.h>' >___build$$$$.c ; \
echo '#include <sys/mkdev.h>' >>___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test -f ___build$$$$.o ; \
then echo '#include <sys/mkdev.h>' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
-echo 'long long foo;' >___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test -f ___build$$$$.o ; \
then echo '#define LONGLONG' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
-echo '#include <sys/types.h>' >___build$$$$.c ; \
echo 'blkcnt_t foo;' >>___build$$$$.c ; \
$(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
if test ! -f ___build$$$$.o ; \
then echo 'typedef long blkcnt_t;' >>config.h ; \
fi ; \
rm -f ___build$$$$.o ___build$$$$.c
Gunnar
Gunnar Ritter
> Ja, ich gehe demnächst, da ich nicht den Eindruck habe, daß die
> jetzige Diskussion dem OP noch irgendwie weiterhilft.
Ja und? Das ist hier keine Supporthotline. Du hast echt ein
komisches Verständnis von Newsgroups und freier Software.
Das setzt sich nicht aus Antwortenden bzw. Programmierern
auf der einen und OPs bzw. dummen Support-Fragern auf der
anderen Seite zusammen. Auf beiden Seiten sitzen Entwickler,
und auf beiden Seiten kann man aus der Kommunikation lernen.
Zum Beispiel könntest Du aus diesem Thread eine Menge lernen.
Und andere Leute, die hier mitlesen, können auch etwas lernen.
Ein einzelner OP ist im Usenet nahezu irrelevant.
Gunnar
Gunnar Ritter
> Würdest Du bei einer Meldung der Art "Warning: The CVS version of this
> package has only been tested with automake 1.7" (ohne, daß das Skript
> an der Stelle abbricht) auch so empfinden, oder wäre das für Dich
> akzeptabel?
Ja, das fände ich okay.
Nur wäre es halt noch tausendmal besser, Du würdest überhaupt kein
automake nehmen.
Gunnar
Martin Dickopp
> Auf beiden Seiten sitzen Entwickler, und auf beiden Seiten kann man
> aus der Kommunikation lernen. Zum Beispiel könntest Du aus diesem
> Thread eine Menge lernen.
Ich habe aus dem Thread durchaus einiges gelernt, wie ich zum Teil
an entsprechender Stelle ja auch geschrieben habe.
Allerdings muß ich zugeben, daß mir nach wie vor unklar ist, welchen
Fehler ich begangen habe, um mir den Zorn mehrerer Regulars
zuzuziehen.
Martin
Gerd Knorr
> Thus spake Gerd Knorr (kra...@bytesex.org):
> > HAVE_SSL := $(shell test -f /usr/include/openssl/ssl.h && echo yes || echo no)
>
> Das ist jetzt nicht dein Ernst, oder?
> Du prüfst nicht mal den Default-Pfad der Standard-Installation?!
Du meinst /usr/local/... ? Könnte man auch testen, ja. Allerdings
waren die openssl-includes auf allen Systemen[1] die ich so auf die
schnelle zwischen die Finger bekommen habe unter /usr und nicht
/usr/local weil openssl inzwischen vielfach zum "Standardlieferumfang"
gehört. Zumindest bei den freien Unixen.
Noch besser würde wohl etwas wie ...
echo '#include <openssl/ssl.h>' | $(CC) $(CFLAGS) -E -
... funkionieren, weil dann auch Tricks a 'la "CFLAGS=-I/foo make" gehen.
Nur das ist schon wieder ziemlich langsam :-/
Gerd
[1] Debian, SuSE, FreeBSD.
King Leo - Martin Oberzalek
> Allerdings muß ich zugeben, daß mir nach wie vor unklar ist, welchen
> Fehler ich begangen habe, um mir den Zorn mehrerer Regulars
> zuzuziehen.
Gar keinen. Is bei diesen Regulars so. :)
Gruß, Martin!
Ps.: Ob sich gleich jemand wegen der länge der Sig aufregt...
--
------------------------
| (__) (__) (__) |
| ( oo (oo) oo ) |
| /\_| /\/\ |_/\ |
------------------------
| The GNU is with me |
------------------------
Thomas Jahns
> Das hat aber gegenüber autoconf-Checks den handfesten Nachteil,
> daß es nicht portabel ist. Ich mache bei einigen kleineren Sachen
> sowas:
>
> config.h:
> -echo '/* Auto-generated by make. Do no edit! */' >config.h
> -echo '#include <wchar.h>' >___build$$$$.c ; \
> $(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
> if test -f ___build$$$$.o ; \
> then echo '#include <wchar.h>' >>config.h ; \
[ 24 Zeilen ähnlichen Inhalts entfernt ]
> if test ! -f ___build$$$$.o ; \
> then echo 'typedef long blkcnt_t;' >>config.h ; \
> fi ; \
> rm -f ___build$$$$.o ___build$$$$.c
Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
wären übermäßig kompliziert. Ich nehme das mal als Anlaß, mich hier
als Fürsprecher der IMHO recht gelungenen Autotools zu betätigen.
Der Hauptvorteil der Autotools besteht nicht darin, von vornherein
schön portablen Code zu produzieren, das muss der Programmierer schon
noch selbst lernen/erledigen. Aber ein mit den Autotools gestricktes
Build-System ermöglicht:
1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
bleiben und ausführlicher output in config.log)
2. einfacheres Handling von Systemen, die sich gegen die Portierung
von Software wehren (nicht vorhandene Libraryfunktionen etc.)
3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
uninstall targets entstehen, und leicht in architekturspezifischen
und ge"/usr/share"ten differenziert werden kann
Und all dies ist dann auch noch für Leute halbwegs verständlich, die
vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
das ganze durch den Compiler treten, so etwas soll ja vorkommen. Diese
Vereinheitlichung der lokalen Montage des vom Programmierer
gelieferten Software-Baukastens ist ein nicht zu unterschätzender
Vorteil, denn für viele Benutzer sind alternative Konzepte, wie sie
z.B. in perl, star oder mgetty (letzteres zumindest früher, ob da
inzwischen umgestellt wurde, entzieht sich meiner Kenntnis) zu finden
sind, auch nach README/INSTALL-Studium eine nicht zu unterschätzende
Hürde.
Es läßt sich eben nicht leugnen, daß der Mensch ein Gewohnheitstier
und noch dazu ein bequemes und tendenziell eher dummes (ich nehme mich
da nicht aus) ist. Software (wie jedes andere technische Produkt)
sollte diesen Aspekt stets berücksichtigen. Deswegen haben
z.B. IDE-Kabel einen Verpolungsschutz und trotzdem schaffen es
vereinzelt Leute das falsch herum 'reinzuwürgen, obwohl ein
hochintelligentes Wesen eigentlich zwei Handbücher zu Rate ziehen
könnte um dann "einfach" die Kontakte zuzuordnen, Trial and error
helfen aber auch, aus eigener Erfahrung kann ich berichten, das
Rechner mit verpolten IDE-Kabeln nicht mal piep sagen, meiner Meinung
nach ein mittelprächtiger Hinweis auf den Fehler.
Ich meine deshalb, es gibt gute Gründe, die Autotools auch bei kleinen
Projekten zu nutzen. Wer Software nur für Schlaue schreibt, verpaßt
den Großteil seines möglichen Publikums.
Thomas Jahns
--
"Computers are good at following instructions,
but not at reading your mind."
D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9
King Leo - Martin Oberzalek
> Gunnar Ritter <g...@bigfoot.de> writes:
>> Das hat aber gegenüber autoconf-Checks den handfesten Nachteil,
>> daß es nicht portabel ist. Ich mache bei einigen kleineren Sachen
>> sowas:
>>
>> config.h:
>> -echo '/* Auto-generated by make. Do no edit! */' >config.h
>> -echo '#include <wchar.h>' >___build$$$$.c ; \
>> $(CC) -c ___build$$$$.c >/dev/null 2>&1 ; \
>> if test -f ___build$$$$.o ; \
>> then echo '#include <wchar.h>' >>config.h ; \
> Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
> wären übermäßig kompliziert. Ich nehme das mal als Anlaß, mich hier
> als Fürsprecher der IMHO recht gelungenen Autotools zu betätigen.
> Ich meine deshalb, es gibt gute Gründe, die Autotools auch bei kleinen
> Projekten zu nutzen. Wer Software nur für Schlaue schreibt, verpaßt
> den Großteil seines möglichen Publikums.
Dann is da noch, die Geschichte, dass das Installationsscriptschreiben bei
den Entwicklern einen ähnlich hohen Stellenwert hat wie das Dokumentieren.
Also, theoretisch ist es das wichtigste, praktisch gibts nur das nötigste.
Gruß, Martin!
Ps.: Nicht, dass das bei mir anders wär...
--
Wozu wechseln? Die Features, die ich bei Linux vermisse,
hat FreeBSD auch nicht.
Gunnar Ritter
>> if test ! -f ___build$$$$.o ; \
>> then echo 'typedef long blkcnt_t;' >>config.h ; \
>> fi ; \
>> rm -f ___build$$$$.o ___build$$$$.c
>
> Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
> wären übermäßig kompliziert.
Wenn Du das kompliziert findest, solltest Du nicht in einer
Programmierer-Gruppe posten. Natürlich ist autobloat nicht
kompliziert, wenn Du nur ein wenig damit rumspielen willst.
Aber wenn Du es verstehen willst, brauchst Du sogar enorm
viel Zeit. Die paar Zeilen Shell da oben kann man hingegen
auf Anhieb verstehen. Und man macht sich damit nicht von
weiteren Tools abhängig. Das sind die Aspekte, die in puncto
Zeit und Komplexität am Ende zählen, nicht, ob es eine oder
eine Handvoll Zeilen sind.
> 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> bleiben und ausführlicher output in config.log)
Genau solche Checks sind es, die einen zur Weißglut bringen,
wenn sie nicht funktionieren. Dann hast Du es nämlich nicht
mehr nur mit einer Handvoll Zeilen Shell zu tun wie oben.
Hast Du noch nicht erlebt, ja? Dann schweige einfach dazu.
> 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> von Software wehren (nicht vorhandene Libraryfunktionen etc.)
autoconf hilft Dir da nicht wirklich weiter. Die Funktionen
darfst Du alle selber schreiben, autoconf führt nur ein paar
Checks durch. Checks von der Art, wie Du sie oben gerade gesehen
hast, offensichtlich ohne sie zu verstehen. Libraryfunktionen
sind wirklich trivial zu checken, mit oder ohne autoconf.
> 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> uninstall targets entstehen, und leicht in architekturspezifischen
> und ge"/usr/share"ten differenziert werden kann
Das hat mit automake nichts zu tun. Nach /usr/share kann man Dateien
auch ohne automake packen, und man kann auch mit automake Dateien
woanders unterbringen. Und die uninstall-Targets von automake
funktionieren ohne Handarbeit auch nicht unbedingt. Du hängst
also mit oder ohne automake vom Willen des Programmierers ab.
> Wer Software nur für Schlaue schreibt, verpaßt den Großteil seines
> möglichen Publikums.
Diese Leute sind irrelevant. Den Programmierer brauchen nur Leute zu
interessieren, die schlau genug sind, um etwas zum Projekt beitragen
zu können. Für Luser gibt es vorkompilierte Binaries oder Ports à la
BSD.
Autobloat vereinfacht das Kompilieren für Deppen auf Kosten derer,
die Ahnung haben. Hätte glatt von Apple kommen können, die Idee.
Gunnar
Felix von Leitner
> Fehler ich begangen habe, um mir den Zorn mehrerer Regulars
> zuzuziehen.
Punkt 1: du bist immer noch hier.
Felix von Leitner
> Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
> wären übermäßig kompliziert. Ich nehme das mal als Anlaß, mich hier
> als Fürsprecher der IMHO recht gelungenen Autotools zu betätigen.
Gegen autoconf an sich ist nicht viel zu sagen, außer daß bei einem
typischen Projekt configure und Freunde 70% des Tarballs ausmachen.
Bei einigen meiner Projekte nahm sogar COPYING die Hälfte der
Distribution ein. Für diese Art von Bloat habe ich kein Verständnis.
> 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> bleiben und ausführlicher output in config.log)
ROTFL.
Generische Fehlermeldungen, my ass.
"checking whether your gcc installation is sane: no".
Sehr hilfreich, das.
Oder hunderte von Folgefehlern. Typische autoconf-Scripte machen am
Anfang irgendwas falsch und fallen danach bei allen weiteren Tests auf
die Schnauze und detecten dann so tolle Sachen wie fehlendes unistd.h,
fehlendes stdio.h, kein openssl, kein libpng etc.
autoconf ist nur in den Händen von echt fähigen Experten hilfreich.
Bei allen anderen macht es mehr Ärger als es einspart.
> 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> von Software wehren (nicht vorhandene Libraryfunktionen etc.)
Bullshit. Gerade solche Systeme werden nur unterstützt, wenn der
Softwareautor so ein System schon mal gesehen hat und weiß, wie man auf
sowas arbeitet. Typische Mülli-autoconf-Systeme benutzen bashismen im
Makefile oder hard-coden Pfade ala /usr/bin/gmake. Alles schon gehabt.
> 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> uninstall targets entstehen, und leicht in architekturspezifischen
> und ge"/usr/share"ten differenziert werden kann
Dafür sind die generierten Makefiles absolut unleserlich, geradezu eine
Zumutung. Es ist außer für automake-Entwickler nicht zumutbar, einen
Bug zu diagnostizieren, wenn er auftritt. Und das Ändern der .am-Datei
führt im Regelfall dank ständiger Inkompatibilitäten zwischen
automake-Versionen zu völlig kaputten Dateien und einem direkt auf die
Schnauze fallenden Build.
> Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> das ganze durch den Compiler treten, so etwas soll ja vorkommen.
Das Gegenteil ist der Fall. Für den typischen Admin sind automake-Bugs
schwieriger zu diagnostizieren als RAM-Fehler. Solche Leute fummeln ein
bißchen rum, verkacken ihre Installation vollständig, und ziehen sich
dann ein Binary-Paket.
automake ist wie keine andere Komponente am Erfolg von
Binär-Distributionen schuld. In ein paar Jahren wird aller Voraussicht
nach überhaupt niemand mehr Pakete aus den Sourcen bauen können, der es
nicht heute schon gekonnt hat. Müll wie automake legt einem dafür
zusehends mehr Steine in den Weg.
Ich erinnere mich noch an Zeiten, wo ich BSD-Software nach Solaris
portiert habe. Das war weniger Streß als heute dieses widerliche
auto*-Gefrickel. Und alles wegen uninformierter Knallköppe wie dir, die
von Portabilität reden und damit meinen, daß es sowohl unter SuSE als
auch RedHat auf ihrem Intel-PC tut. Ich sehe keinen Unterschied mehr zu
undurchsichtigen Microsoft-"Lösungen".
> Diese Vereinheitlichung der lokalen Montage des vom Programmierer
> gelieferten Software-Baukastens ist ein nicht zu unterschätzender
> Vorteil, denn für viele Benutzer sind alternative Konzepte, wie sie
> z.B. in perl, star oder mgetty (letzteres zumindest früher, ob da
> inzwischen umgestellt wurde, entzieht sich meiner Kenntnis) zu finden
> sind, auch nach README/INSTALL-Studium eine nicht zu unterschätzende
> Hürde.
Die auto*-Pakete mit einem anständigen README/INSTALL kann man an zwei
Fingern abzählen.
Sag mal, sind bei epost.de eigentlich nur Deppen? So langsam könnte ich
signifikante Teile meines Scorefiles mit einem epost-Domain-Plonk
konsolidieren.
> Ich meine deshalb, es gibt gute Gründe, die Autotools auch bei kleinen
> Projekten zu nutzen. Wer Software nur für Schlaue schreibt, verpaßt
> den Großteil seines möglichen Publikums.
Warum unterhälst du dich nicht lieber über Sachen, mit denen du dich
auskennst?
Rainer Weikusat
> Aber ein mit den Autotools gestricktes
> Build-System ermöglicht:
>
> 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> bleiben
Typischerweise bedeutet 'falscher Pfad hartkodiert'.
> Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> das ganze durch den Compiler treten, so etwas soll ja vorkommen.
Kannst Du Dir vorstellen, warum ich folgendes Skript benutze?
---------------
#!/bin/sh
#
C_INCLUDE_PATH=/usr/local/openssl-0.9.7/include \
LIBRARY_PATH=/usr/local/openssl-0.9.7/lib gmake
---------------
Hint: Nicht deswegen, weil es so unglaublich einfach ist,
ersatzweise geeignete configure-Optionen nachzurüsten,
die durch eine mehrstufige Verzeichnishierarchie propagiert
werden müssen (nicht kompliziert, aber zeitraubend).
Gerd Knorr
> Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> bleiben und ausführlicher output in config.log)
Das ist autoconf. Und das ist der einzige Teil der ganzen auto* Familie
den ich deswegen auch für ganz brauchbar halte.
> 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> von Software wehren (nicht vorhandene Libraryfunktionen etc.)
parse error. Was genau wolltest Du hier gerade sagen?
> 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> uninstall targets entstehen, und leicht in architekturspezifischen
> und ge"/usr/share"ten differenziert werden kann
Allerdings um den Preis hochkomplexer und unlesbarer Makefiles.
Schon mal den Fall gehabt daß das installieren nicht so geklappt hat wie
gewollt? Kommt öfter vor wenn man in ein buildroot unter $TMDIR/foo
installieren will um RPMs zu bauen. Schon mal versucht den output von
"make -n install" eines automake buildsystems zu verstehen, um den
Fehler zu finden? Oder gar das Makefile selber?
Die Syntax von Makefile.am hat auch nur sehr entfernt was mit Makefiles
zu tun. Viele nette Sachen die in normalen Makefiles prima funkionieren
gehen in Makefile.am nicht, weil automake damit nicht klarkommt.
Im übrigen überlasse ich den job des "make uninstall" lieber rpm oder
dpkg, schon deswegen weil ich die source-trees nicht ewig herumliegen
lassen will.
> Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> das ganze durch den Compiler treten, so etwas soll ja vorkommen. Diese
> Vereinheitlichung der lokalen Montage des vom Programmierer
> gelieferten Software-Baukastens ist ein nicht zu unterschätzender
> Vorteil,
Das geht auch ohne autotools, mit den üblichen make targets (all,
install).
Thomas Jahns
> Thomas Jahns <Thomas...@epost.de> wrote:
>
> >> if test ! -f ___build$$$$.o ; \
> >> then echo 'typedef long blkcnt_t;' >>config.h ; \
> >> fi ; \
> >> rm -f ___build$$$$.o ___build$$$$.c
> >
> > Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
> > wären übermäßig kompliziert.
>
> Wenn Du das kompliziert findest, solltest Du nicht in einer
> Programmierer-Gruppe posten. Natürlich ist autobloat nicht
> kompliziert, wenn Du nur ein wenig damit rumspielen willst.
> Aber wenn Du es verstehen willst, brauchst Du sogar enorm
> viel Zeit. Die paar Zeilen Shell da oben kann man hingegen
> auf Anhieb verstehen. Und man macht sich damit nicht von
> weiteren Tools abhängig. Das sind die Aspekte, die in puncto
> Zeit und Komplexität am Ende zählen, nicht, ob es eine oder
> eine Handvoll Zeilen sind.
Das Erstellen von portablen sh-Skripten ist nur leider alles andere als
einfach, wie von den autoconf-Entwicklern in einem ganzen Kapitel
beschrieben. Autoconf bietet eigentlich in 90% der Fälle die
Möglichkeit, ohne potentiell nicht-portablen sh-code auszukommen. (Von
manchmal nötigen Trivialkonstruktionen a la if;then;else mal
abgesehen). Für die angesprochenen einfachen Projekte kann autoconf
einem das meist ganz ersparen.
> > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> > bleiben und ausführlicher output in config.log)
>
> Genau solche Checks sind es, die einen zur Weißglut bringen,
> wenn sie nicht funktionieren. Dann hast Du es nämlich nicht
> mehr nur mit einer Handvoll Zeilen Shell zu tun wie oben.
> Hast Du noch nicht erlebt, ja? Dann schweige einfach dazu.
Nur sind eben diese Resultate genau das, was das configure-Skript ohne
KI-Erweiterung feststellen kann. Und da die meisten
configure.in/.ac-Skripte gut bekannte Makros recyclen, weiß man
typischerweise schon nach wenigen Builds, wofür die Meldung steht und
wie man sie beheben kann. Wenn man das jedesmal neu herausfinden muss,
weil jeder der Meinung ist, seine selbstgeschriebenen sh-Skripte seien
die ultimative Antwort, so ist das mehr als nervig.
Natürlich habe ich schon komplizierte Konstruktionen erlebt, die
sowohl in Bezug auf m4 als auch den erzeugten sh-code recht
anspruchsvoll waren (lies: komplizierter als nötig). Aber darüber, ob
die Wahrscheinlichkeit für schwer verständliche Konstruktionen mit der
Verwendung der autotools abnimmt, sind wir ja ganz offensichtlich
unterschiedlicher Meinung.
> > 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> > von Software wehren (nicht vorhandene Libraryfunktionen etc.)
>
> autoconf hilft Dir da nicht wirklich weiter. Die Funktionen
> darfst Du alle selber schreiben, autoconf führt nur ein paar
> Checks durch. Checks von der Art, wie Du sie oben gerade gesehen
> hast, offensichtlich ohne sie zu verstehen. Libraryfunktionen
> sind wirklich trivial zu checken, mit oder ohne autoconf.
Ich meinte auch sowohl autoconf als auch automake, denn beide sind ein
geprüftes Gespann für conditional compilation, um fehlerhafte oder
fehlende Funktionen im BS zu ersetzen. Dadurch programmiert man nur
für eine Schnittstelle (typischerweise Posix, kann aber auch jede
andere sein, es wird dadurch aber nicht unbedingt leichter). Und wenn
man sich ein wenig umsieht, findet man durchaus einige fertige
Lösungen, schon das eher magere "Autoconf Macro Archive" enthält viele
brauchbare Ansätze.
> > 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> > uninstall targets entstehen, und leicht in architekturspezifischen
> > und ge"/usr/share"ten differenziert werden kann
>
> Das hat mit automake nichts zu tun. Nach /usr/share kann man Dateien
> auch ohne automake packen, und man kann auch mit automake Dateien
> woanders unterbringen. Und die uninstall-Targets von automake
> funktionieren ohne Handarbeit auch nicht unbedingt. Du hängst
> also mit oder ohne automake vom Willen des Programmierers ab.
Ich habe auch nicht behauptet, daß das nicht ginge, ich glaube aber,
daß automake es besonders einfach macht. Alles, was mit den autotools
geht, kann man auch selbst erstellen, nur habe ich wenig Verlangen,
das Rad jedesmal neu zu erfinden.
> > Wer Software nur für Schlaue schreibt, verpaßt den Großteil seines
> > möglichen Publikums.
>
> Diese Leute sind irrelevant. Den Programmierer brauchen nur Leute zu
> interessieren, die schlau genug sind, um etwas zum Projekt beitragen
> zu können. Für Luser gibt es vorkompilierte Binaries oder Ports à la
> BSD.
>
> Autobloat vereinfacht das Kompilieren für Deppen auf Kosten derer,
> die Ahnung haben. Hätte glatt von Apple kommen können, die Idee.
Wie ich in meinen letzten Absätzen auszudrücken versuchte, bin ich der
Ansicht, daß wir uns alle nicht immer und ständig durch sonderliche
Klugheit hervortun. Man kann natürlich so tun, als wäre man nur von
Wesen gottgleicher Ein- und Weitsicht umgeben. Wenn letzteres bei Dir
sogar den Tatsachen entspricht, kann ich Dich nur beneiden.
Thomas Jahns
> > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> > bleiben und ausführlicher output in config.log)
>
> Das ist autoconf. Und das ist der einzige Teil der ganzen auto* Familie
> den ich deswegen auch für ganz brauchbar halte.
Da bist Du offenbar einer der wenigen, die nicht nur den konkreten
kurzen Text sondern die dahinterstehende Methode sehen.
> > 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> > von Software wehren (nicht vorhandene Libraryfunktionen etc.)
>
> parse error. Was genau wolltest Du hier gerade sagen?
Ich wollte damit ausdrücken, daß autoconf einen IMHO leicht
erlernbaren Weg darstellt, um fehlende/fehlerhafte API-Funktionen zu
identifizieren, bei Bedarf durch eigenen (oder auch fremden) Code zu
ersetzen und schließlich in das fertige Programm einzubinden.
> > 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> > uninstall targets entstehen, und leicht in architekturspezifischen
> > und ge"/usr/share"ten differenziert werden kann
>
> Allerdings um den Preis hochkomplexer und unlesbarer Makefiles.
Jein, was ich da an handverzapftem gesehen habe, war auch nicht gerade
berauschend. Ich glaube nicht, daß Makefiles auf Dauer durch
kristallklare Struktur glänzen können, dazu wird die Zahl der
Eventualitäten mit der Zahl der unterstützten Systeme einfach zu groß.
> Schon mal den Fall gehabt daß das installieren nicht so geklappt hat wie
> gewollt? Kommt öfter vor wenn man in ein buildroot unter $TMDIR/foo
> installieren will um RPMs zu bauen. Schon mal versucht den output von
> "make -n install" eines automake buildsystems zu verstehen, um den
> Fehler zu finden? Oder gar das Makefile selber?
RPMs habe ich bisher tatsächlich nicht gebaut, das empfand ich bei der
geringen Zahl der verwalteten Systeme einfach nicht zweckmäßig. Aber
daß ein Installationsvorgang nicht wie gewünscht funktioniert kenne
ich zur Genüge. In meiner Erfahrung bereiten allerdings
selbstgeschriebene Makefiles mit fehlerhaften Annahmen z.B. bezüglich
/usr/bin/install genauso viele Probleme und sind durchaus nicht einmal
in der Mehrzahl der Fälle einfacher zu lösen, als selbst eine lokale
Variante des Makefiles fast von Grund auf zu erstellen.
> Die Syntax von Makefile.am hat auch nur sehr entfernt was mit Makefiles
> zu tun. Viele nette Sachen die in normalen Makefiles prima funkionieren
> gehen in Makefile.am nicht, weil automake damit nicht klarkommt.
Soll es auch gar nicht. automake dient exakt dem Zweck das
Makefile-Schreiben möglichst stark zu abstrahieren. Esoterische
Funktionen (mir kommt gerade keine geeignete in den Sinn, ich liefere
ein Beispiel nach, sobald es mir einfällt) müßten dann wohl in (dann
ebenfalls portablen) Skripten erschlagen werden.
> Im übrigen überlasse ich den job des "make uninstall" lieber rpm oder
> dpkg, schon deswegen weil ich die source-trees nicht ewig herumliegen
> lassen will.
In meiner Wahrnehmung ist das "Verschwenden" von Speicherplatz
billiger als meine Zeit jedesmal für das Entwickeln von
OS-spezifischen Paketen aufzuwenden (wir sprechen hier von der
Vielzahl fremder Software und nicht den tendenziell wenigeren eigenen
Projekten?)
> > Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> > vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> > das ganze durch den Compiler treten, so etwas soll ja vorkommen. Diese
> > Vereinheitlichung der lokalen Montage des vom Programmierer
> > gelieferten Software-Baukastens ist ein nicht zu unterschätzender
> > Vorteil,
>
> Das geht auch ohne autotools, mit den üblichen make targets (all,
> install).
Nur ist die Arbeit, diese targets plattformübergreifend zu erzeugen
alles andere als einfach. Das ist doch gerade der springende Punkt bei
den autotools. Im von mir genannten Beispiel mgetty hat es sicher auch
einmal mit wenigen und einfachen Ausnahmen/Anpassungen
angefangen. Aber als ich das Paket (für ein in der Standard-distri
nicht verfügbares Feature) ca. 1997 selbst bauen mußte, war das durch
die reine Vielzahl an notwendigen Änderungen im Makefile wirklich
nicht einfach und auch wenn ich heute keine Verwendung für die
Software mehr habe, so hoffe ich doch im Sinne aller Maintainer, daß
sich an dieser Situation etwas geändert hat.
> --
> You can't please everybody. And usually if you _try_ to please
> everybody, the end result is one big mess.
> -- Linus Torvalds, 2002-04-20
Durchaus nicht ohne Weisheit. Auch wenn andere den Bezug zum Thema
sicherlich anders interpretieren als ich.
Thomas Jahns
> typischen Projekt configure und Freunde 70% des Tarballs ausmachen.
Da handelt es sich dann aber um wirklich kleine Pakete, und daß das
nicht bedeutet, daß der Entwickler tatsächlich 70% seiner Zeit für das
Schreiben dieser Skripte/Makefile.in's aufgewandt hat ist wohl auch
klar.
> Bei einigen meiner Projekte nahm sogar COPYING die Hälfte der
> Distribution ein. Für diese Art von Bloat habe ich kein Verständnis.
Das darf man wohl eher der (amerikanischen) Rechtsordnung zuschreiben,
als dafür den Programmierer verantwortlich zu machen.
> > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> > bleiben und ausführlicher output in config.log)
>
> ROTFL.
> Generische Fehlermeldungen, my ass.
> "checking whether your gcc installation is sane: no".
> Sehr hilfreich, das.
Wie ich schon schrieb, sind die Fehlermeldungen aber meist gleich, also
vertraut. Und diese Ausgabe ist die kürzeste und dennoch richtige
Möglichkeit. Schreib mal eine ausführliche Fehlermeldung im voraus,
die den tatsächlich vorliegenden Sachverhalt besser beschreibt, als
die Fehlermeldungen in config.log.
> Oder hunderte von Folgefehlern. Typische autoconf-Scripte machen am
> Anfang irgendwas falsch und fallen danach bei allen weiteren Tests auf
> die Schnauze und detecten dann so tolle Sachen wie fehlendes unistd.h,
> fehlendes stdio.h, kein openssl, kein libpng etc.
Das ist ja wohl auch bei fast allen compilern so, daß meist nur die erste
Fehlermeldung wirklich sinnvoll zur Fehlersuche herangezogen werden
kann, also wohl kaum ein überraschender Umstand. Tatsächlich wäre es
wohl besser, wenn das configure-Skript sich nach solch fatalen
Befunden sofort beendet und das kann man auch leicht implementieren.
> autoconf ist nur in den Händen von echt fähigen Experten hilfreich.
> Bei allen anderen macht es mehr Ärger als es einspart.
>
> > 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> > von Software wehren (nicht vorhandene Libraryfunktionen etc.)
>
> Bullshit. Gerade solche Systeme werden nur unterstützt, wenn der
> Softwareautor so ein System schon mal gesehen hat und weiß, wie man auf
> sowas arbeitet. Typische Mülli-autoconf-Systeme benutzen bashismen im
> Makefile oder hard-coden Pfade ala /usr/bin/gmake. Alles schon gehabt.
Wenn aber nur eine Funktion fehlt (z.B. vsnprintf(3)) dann ist mit den
autotools verhältnismäßig leicht, das in einer bei allen Projekten,
die autotools und die fehlende Funktion verwenden, gleichen Weise
einzubauen. Ich nehme da als Beispiel mal die
gettext/libintl-Unterstützung: überall gleich (und leider auch lange
fehlerhaft), für den einzelnen Projekt-Autor aber mit verschwindend
geringem Aufwand verfügbar.
Daß Leute, die vpath-builds nie ausprobiert haben, oder in $srcdir
feste Pfade ablegen, so daß man das Oberverzeichnis von build- und
source-Tree nicht verschieben kann, stelle ich gar nicht in Abrede.
Aber die gleichen Leute sind nach meiner Einschätzung bei der
Neuerfindung des Rades durch Erstellen eines eigenen Systems für den
build- und Installationsprozess auch nicht weniger, sondern mehr in
Gefahr einen Alptraum für andere zu produzieren.
> > 3. automake ist gerade deswegen nützlich, weil z.B. automatisch auch
> > uninstall targets entstehen, und leicht in architekturspezifischen
> > und ge"/usr/share"ten differenziert werden kann
>
> Dafür sind die generierten Makefiles absolut unleserlich, geradezu eine
> Zumutung. Es ist außer für automake-Entwickler nicht zumutbar, einen
> Bug zu diagnostizieren, wenn er auftritt. Und das Ändern der .am-Datei
> führt im Regelfall dank ständiger Inkompatibilitäten zwischen
> automake-Versionen zu völlig kaputten Dateien und einem direkt auf die
> Schnauze fallenden Build.
Wie jemand anderes bereits schrieb, ist man auch selbst Schuld, wenn
man versucht ein Makefile.am für mehrere automake-Versionen zu
schreiben.
>
> > Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> > vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> > das ganze durch den Compiler treten, so etwas soll ja vorkommen.
>
> Das Gegenteil ist der Fall. Für den typischen Admin sind automake-Bugs
> schwieriger zu diagnostizieren als RAM-Fehler. Solche Leute fummeln ein
> bißchen rum, verkacken ihre Installation vollständig, und ziehen sich
> dann ein Binary-Paket.
Meine diesbezügliche Erfahrung ist (mit Ausnahme solch grauenhafter
Monster wie KDE oder Gnome) eine andere.
> automake ist wie keine andere Komponente am Erfolg von
> Binär-Distributionen schuld. In ein paar Jahren wird aller Voraussicht
> nach überhaupt niemand mehr Pakete aus den Sourcen bauen können, der es
> nicht heute schon gekonnt hat. Müll wie automake legt einem dafür
> zusehends mehr Steine in den Weg.
Das vornehmlich Bequemlichkeit und Arbeitsteilung sowie
Sicherheitsbedenken diesen Umstand befördern könnten, kommt Dir nicht
in den Sinn? Ich bilde mir nicht ein, meine 3 Entwickler-Systeme mit
jeweils mehreren hundert installierten Paketen auf einem aktuellen und
konsistenten Stand zu halten, indem ich alles durch händisches
Erstellen selbst kompiliere. Die theoretische Möglichkeit mag
bestehen, aber a) ist mir meine Zeit zu kostbar und b) bin ich
durchaus in der Lage die Arbeit von anderen zu würdigen. Das
Bereitstellen eines vernünftig gepflegten Pakets ist bei größeren
Projekten alles andere als einfach und mit viel Abwägen verbunden.
> Ich erinnere mich noch an Zeiten, wo ich BSD-Software nach Solaris
> portiert habe. Das war weniger Streß als heute dieses widerliche
> auto*-Gefrickel. Und alles wegen uninformierter Knallköppe wie dir, die
> von Portabilität reden und damit meinen, daß es sowohl unter SuSE als
> auch RedHat auf ihrem Intel-PC tut. Ich sehe keinen Unterschied mehr zu
> undurchsichtigen Microsoft-"Lösungen".
Das Portieren von einer Plattform auf eine einzelne andere ist wohl
immer einfacher, als für ein API auf mehreren Plattformen zu
schreiben und gleichzeitig das API selbst (teilweise) auf allen
unterstützten Plattformen zur Verfügung zu stellen. Die Probleme, die
die autotools zu lösen versuchen, sind da eine Nummer größer als von
BSD nach Solaris. Denn die einfache Portierung durch Anpassen des
Kern-Programmcodes an die verschieden System-APIs führt fast
unweigerlich zum Fork in verschiedene Entwicklungsstränge oder
Alpträume aus #ifdef-Schachtelungen (womit ich nicht unterstelle, daß
Du so vorgegangen bist).
Ich gebe zu, mich nicht um sehr viele Plattformen selbst zu scheren
(SuSE, debian, IRIX 6.5, sowie AIX 4.x, alle nicht so verschieden),
bin aber der Ansicht, daß die autotools denjenigen, die die Programme
schließlich auf Plattformen jenseits des Horizonts des Entwicklers
einsetzen, die Arbeit erleichtern.
> > Diese Vereinheitlichung der lokalen Montage des vom Programmierer
> > gelieferten Software-Baukastens ist ein nicht zu unterschätzender
> > Vorteil, denn für viele Benutzer sind alternative Konzepte, wie sie
> > z.B. in perl, star oder mgetty (letzteres zumindest früher, ob da
> > inzwischen umgestellt wurde, entzieht sich meiner Kenntnis) zu finden
> > sind, auch nach README/INSTALL-Studium eine nicht zu unterschätzende
> > Hürde.
>
> Die auto*-Pakete mit einem anständigen README/INSTALL kann man an zwei
> Fingern abzählen.
Du wärest nicht so freundlich, auch zu erklären, was mit anständig
gemeint ist? Nicht daß ich keine Vorstellung hätte, aber die muß ja
nicht deckungsgleich mit Deiner sein.
> Sag mal, sind bei epost.de eigentlich nur Deppen? So langsam könnte ich
> signifikante Teile meines Scorefiles mit einem epost-Domain-Plonk
> konsolidieren.
Die Bezeichnung von Leuten, die eine andere Meinung vertreten, als
"Deppen" stelle ich Dir in _meinem Falle_ frei, aber vielleicht solltest
Du berücksichtigen, daß andere Erfahrungen auch zu anderen Ansichten
und Schlußfolgerungen führen und weder die eine noch die andere
Meinung "falsch" sein muß. Letzteres in allen Lebenslagen entscheiden
zu können, ist eine Wahrnehmungsdeformation, die man eigentlich nur
mittels eines Jura-Studiums erwirbt.
> > Ich meine deshalb, es gibt gute Gründe, die Autotools auch bei kleinen
> > Projekten zu nutzen. Wer Software nur für Schlaue schreibt, verpaßt
> > den Großteil seines möglichen Publikums.
>
> Warum unterhälst du dich nicht lieber über Sachen, mit denen du dich
> auskennst?
Wie ganz oben in meinem ersten Posting zum Thema gesagt, vertrete ich
einen Standpunkt. Es ist nicht meine Absicht zu behaupten, deiner wäre
falsch, aber ich nehme für mich in Anspruch, gute Gründe für den
meinen zu haben.
Thomas Jahns
> Thomas Jahns <Thomas...@epost.de> wrote:
>
> >> if test ! -f ___build$$$$.o ; \
> >> then echo 'typedef long blkcnt_t;' >>config.h ; \
> >> fi ; \
> >> rm -f ___build$$$$.o ___build$$$$.c
> >
> > Schrieb da einer, der meinte die Autotools bräuchten viel Zeit und
> > wären übermäßig kompliziert.
>
> Wenn Du das kompliziert findest, solltest Du nicht in einer
> Programmierer-Gruppe posten. Natürlich ist autobloat nicht
> kompliziert, wenn Du nur ein wenig damit rumspielen willst.
Mit kompliziert meinte ich übrigens nicht die Transparenz der
Konstruktion sondern die Klarheit des Ausdrucks.
Thomas Jahns
> Thomas Jahns <Thomas...@epost.de> writes:
> > Aber ein mit den Autotools gestricktes
> > Build-System ermöglicht:
> >
> > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> > bleiben
>
> Typischerweise bedeutet 'falscher Pfad hartkodiert'.
Ist es also besser, dem Anwender durch eine dementsprechende Meldung
einen eventuell irreführenden Hinweis zu geben?
> > Und all dies ist dann auch noch für Leute halbwegs verständlich, die
> > vielleicht nicht gerade Programmierer sind, sondern als Sysadmins nur
> > das ganze durch den Compiler treten, so etwas soll ja vorkommen.
>
> Kannst Du Dir vorstellen, warum ich folgendes Skript benutze?
>
> ---------------
> #!/bin/sh
> #
>
> C_INCLUDE_PATH=/usr/local/openssl-0.9.7/include \
> LIBRARY_PATH=/usr/local/openssl-0.9.7/lib gmake
> ---------------
>
> Hint: Nicht deswegen, weil es so unglaublich einfach ist,
> ersatzweise geeignete configure-Optionen nachzurüsten,
> die durch eine mehrstufige Verzeichnishierarchie propagiert
> werden müssen (nicht kompliziert, aber zeitraubend).
Natürlich kann ich mir das vorstellen, es erspart Schreibarbeit und
Tippfehler (vorausgesetzt der Name des Skripts ist auch kürzer, was
ich einmal annehme), aber das Finden von Installationsorten ist auch
nicht in jedem Fall die Aufgabe von autoconf. Exakt dieses Beispiel
würde in autoconf durch
#!/bin/sh
CFLAGS="-I/usr/local/openssl-0.9.7/include" \
LDFLAGS="-L/usr/local/openssl-0.9.7/lib" /path/to/configure
realisiert. Da kann ich jetzt nicht genau erkennen, in welcher Weise
beides differiert. Der Unterschied ergibt sich ja wohl vielmehr
dadurch, daß man sich mit automake erspart, die rekursiven Makefiles
selbst zu schreiben. Ob das in Deinem Fall schneller ist, kann ich
nicht sagen.
Selbst wenn solche Informationen mittels z.B. libmikmod-config in
Erfahrung gebracht werden, muß vorher der PATH stimmen.
Felix von Leitner
> > Thus spake Thomas Jahns (Thomas...@epost.de):
> > Gegen autoconf an sich ist nicht viel zu sagen, außer daß bei einem
> > typischen Projekt configure und Freunde 70% des Tarballs ausmachen.
> Da handelt es sich dann aber um wirklich kleine Pakete,
Nein.
> und daß das nicht bedeutet, daß der Entwickler tatsächlich 70% seiner
> Zeit für das Schreiben dieser Skripte/Makefile.in's aufgewandt hat ist
> wohl auch klar.
Die Zeit des Entwicklers geht mir _vollständig_ am Arsch vorbei.
Ich als Enduser ziehe mir diesen Bullshit und zahle für die Bandbreite
und den Lagerplatz. Der Anbieter zahlt normalerweise auch für seine
Bandbreite, umso weniger verzeihlich ist es, wenn er da unnötig
rumbloatet.
Typisches GNU-Paket: GNU fileutils. Die größten 10 Dateien sind:
-rwxr-xr-x 1 leitner users 656917 Apr 29 2001 configure
-rw-r--r-- 1 leitner users 249223 Apr 2 2001 lib/regex.c
-rw-r--r-- 1 leitner users 223087 Feb 22 1998 ChangeLog-1997
-rw-r--r-- 1 leitner users 215535 Apr 29 2001 ChangeLog
-rw-r--r-- 1 leitner users 205887 Apr 21 2001 doc/texinfo.tex
-rw-r--r-- 1 leitner users 169243 Apr 29 2001 doc/fileutils.info
-rw-r--r-- 1 leitner users 133836 Apr 29 2001 po/es.po
-rw-r--r-- 1 leitner users 124073 Apr 29 2001 aclocal.m4
-rw-r--r-- 1 leitner users 111767 Apr 23 2001 doc/fileutils.texi
-rw-r--r-- 1 leitner users 107647 Apr 29 2001 po/fr.po
Ganz großartig. Überhaupt: 650k configure-Script?! Mein erster PC
hatte weniger RAM als GNU hier in Form eines Scripts rauskloppt!
> > ROTFL.
> > Generische Fehlermeldungen, my ass.
> > "checking whether your gcc installation is sane: no".
> > Sehr hilfreich, das.
> Wie ich schon schrieb, sind die Fehlermeldungen aber meist gleich, also
> vertraut.
Das hilft mir ungemein, wenn mir schon bei den letzten fünfzehn
vim-Versionen diese Fehlermeldung auf den Fuß gefallen ist, weil die
vim-Autoren finden, daß Cross-Compiler zu selten sind, als daß man sie
unterstützen sollte.
> Und diese Ausgabe ist die kürzeste und dennoch richtige
> Möglichkeit.
Bullshit.
> Schreib mal eine ausführliche Fehlermeldung im voraus, die den
> tatsächlich vorliegenden Sachverhalt besser beschreibt, als die
> Fehlermeldungen in config.log.
Der Sachverhalt ist, daß ich vim cross-compilen wollte.
NATÜRLICH ist meine Compiler-Umgebung sane.
> > Oder hunderte von Folgefehlern. Typische autoconf-Scripte machen am
> > Anfang irgendwas falsch und fallen danach bei allen weiteren Tests auf
> > die Schnauze und detecten dann so tolle Sachen wie fehlendes unistd.h,
> > fehlendes stdio.h, kein openssl, kein libpng etc.
> Das ist ja wohl auch bei fast allen compilern so, daß meist nur die erste
> Fehlermeldung wirklich sinnvoll zur Fehlersuche herangezogen werden
> kann, also wohl kaum ein überraschender Umstand. Tatsächlich wäre es
> wohl besser, wenn das configure-Skript sich nach solch fatalen
> Befunden sofort beendet und das kann man auch leicht implementieren.
Nur tut GNU configure den Bullshit dann in einen Cache, wo man ihn
dann manuell austragen muß, nachdem man die Bugs in configure fixen
mußte.
> > autoconf ist nur in den Händen von echt fähigen Experten hilfreich.
> > Bei allen anderen macht es mehr Ärger als es einspart.
> >
Das mit dem Quoten üben wir aber noch mal...
> > Bullshit. Gerade solche Systeme werden nur unterstützt, wenn der
> > Softwareautor so ein System schon mal gesehen hat und weiß, wie man auf
> > sowas arbeitet. Typische Mülli-autoconf-Systeme benutzen bashismen im
> > Makefile oder hard-coden Pfade ala /usr/bin/gmake. Alles schon gehabt.
> Wenn aber nur eine Funktion fehlt (z.B. vsnprintf(3)) dann ist mit den
> autotools verhältnismäßig leicht, das in einer bei allen Projekten,
> die autotools und die fehlende Funktion verwenden, gleichen Weise
> einzubauen.
ROTFL, guter Plan!
Wir bloaten am besten jedes einzelne Softwarepaket mit einer halben
libc-Implementation auf, damit die Hersteller von kaputten Müll-Unixen
keine Notwendigkeit haben, ihren Schrott zu fixen. Toller Plan.
Ich kann förmlich vor mir sehen, wie gut der funktioniert. Man sieht ja
schon, wie toll er in den letzten Jahren funktioniert hat. Gar nicht.
> Ich nehme da als Beispiel mal die gettext/libintl-Unterstützung:
> überall gleich (und leider auch lange fehlerhaft), für den einzelnen
> Projekt-Autor aber mit verschwindend geringem Aufwand verfügbar.
Dafür sind die autoconf-Deppen häufig zu dämlich, --disable-nls
anzubieten.
> Daß Leute, die vpath-builds nie ausprobiert haben, oder in $srcdir
> feste Pfade ablegen, so daß man das Oberverzeichnis von build- und
> source-Tree nicht verschieben kann, stelle ich gar nicht in Abrede.
> Aber die gleichen Leute sind nach meiner Einschätzung bei der
> Neuerfindung des Rades durch Erstellen eines eigenen Systems für den
> build- und Installationsprozess auch nicht weniger, sondern mehr in
> Gefahr einen Alptraum für andere zu produzieren.
Ach was. Der absolute Ultra-Albtraum sind Pseudo-Experten wie Herr
Schily, die sich auch noch im Recht wähnen, wenn sie irgendwelche
untransparenten Buildsysteme bauen, die am Ende auch nur autoconf
aufrufen, aber zu dämlich sind, dem User die üblichen autoconf-Optionen
anzubieten.
/opt/schily. Ich könnte kübelweise kotzen über sowas.
> > Dafür sind die generierten Makefiles absolut unleserlich, geradezu eine
> > Zumutung. Es ist außer für automake-Entwickler nicht zumutbar, einen
> > Bug zu diagnostizieren, wenn er auftritt. Und das Ändern der .am-Datei
> > führt im Regelfall dank ständiger Inkompatibilitäten zwischen
> > automake-Versionen zu völlig kaputten Dateien und einem direkt auf die
> > Schnauze fallenden Build.
> Wie jemand anderes bereits schrieb, ist man auch selbst Schuld, wenn
> man versucht ein Makefile.am für mehrere automake-Versionen zu
> schreiben.
Klar, nicht das völlig kaputte Schrott-Müll-Scheiß-Kack-Utility
"automake" ist schuld daran, daß es die Welt mit Albtraum-Müllcode
zupflastert, sondern die Programmierer, die versuchen, zu mehreren
Versionen kompatibel zu sein. Merkst du eigentlich noch was? Die
Herstellung von Kompatibilität ist die Hauptaufgabe von Programmierern!
> > Das Gegenteil ist der Fall. Für den typischen Admin sind automake-Bugs
> > schwieriger zu diagnostizieren als RAM-Fehler. Solche Leute fummeln ein
> > bißchen rum, verkacken ihre Installation vollständig, und ziehen sich
> > dann ein Binary-Paket.
> Meine diesbezügliche Erfahrung ist (mit Ausnahme solch grauenhafter
> Monster wie KDE oder Gnome) eine andere.
Klar, für die funktionierende Software ist automake toll, außer man
versucht, die Scripte zu lesen. Diese Fälle deklarierst du einfach zu
Monster-Software und kommst dann mit der grandiosen Aussage, daß das nur
bei Monster-Software schlecht ist. Ganz tolle Aussage, das.
Merkbefreiung jetzt!
> Das vornehmlich Bequemlichkeit und Arbeitsteilung sowie
> Sicherheitsbedenken diesen Umstand befördern könnten, kommt Dir nicht
> in den Sinn?
Sicherheitsbedenken?!
Das ist ja wohl die dämlichste Begründung, auf Binärpakete umzusteigen,
die ich je gehört habe. Du mußt ja wirklich unglaublich stoned sein.
Darf ich fragen, was für Stoff du da gerade zu dir nimmst?
> Das Portieren von einer Plattform auf eine einzelne andere ist wohl
> immer einfacher, als für ein API auf mehreren Plattformen zu
> schreiben und gleichzeitig das API selbst (teilweise) auf allen
> unterstützten Plattformen zur Verfügung zu stellen. Die Probleme, die
> die autotools zu lösen versuchen, sind da eine Nummer größer als von
> BSD nach Solaris. Denn die einfache Portierung durch Anpassen des
> Kern-Programmcodes an die verschieden System-APIs führt fast
> unweigerlich zum Fork in verschiedene Entwicklungsstränge oder
> Alpträume aus #ifdef-Schachtelungen (womit ich nicht unterstelle, daß
> Du so vorgegangen bist).
BSD und Solaris _sind_ verschiedene APIs! Solaris ist System V!
Weißt du eigentlich überhaupt irgendwas über die Themen, über die du
hier herumschwadronierst?
Meine Güte, ich ziehe Leute wie dich in letzter Zeit offenbar irgendwie
an. Ist ja fürchterlich.
> > Die auto*-Pakete mit einem anständigen README/INSTALL kann man an zwei
> > Fingern abzählen.
> Du wärest nicht so freundlich, auch zu erklären, was mit anständig
> gemeint ist? Nicht daß ich keine Vorstellung hätte, aber die muß ja
> nicht deckungsgleich mit Deiner sein.
Ein README-File sollte beschreiben, was das Paket tut, warum man es
installieren will, welche Alternativen aus welchen Gründen schlechter
sind, und wer der Autor ist und wie man Bugs melden kann. Außerdem
sollte es eine rudimentäre Einführung beinhalten, wie man mit der
Software umgeht.
Ein INSTALL-File sollte beschreiben, wie man die Software installiert,
welche Konfigurationsoptionen es gibt, wie man die Software wieder los
wird, und was für Compile Time Einstellungen es gibt, von denen man
wissen muß.
Der meiste auto*-Müll liefert das generische INSTALL-File von autoconf
mit. Das ist absolut überflüssige Platzverschwendung und eine
Frechheit gegenüber dem Enduser.
Felix
King Leo - Martin Oberzalek
> Gerd Knorr <kra...@bytesex.org> writes:
>> Schon mal den Fall gehabt daß das installieren nicht so geklappt hat wie
>> gewollt? Kommt öfter vor wenn man in ein buildroot unter $TMDIR/foo
>> installieren will um RPMs zu bauen. Schon mal versucht den output von
>> "make -n install" eines automake buildsystems zu verstehen, um den
>> Fehler zu finden? Oder gar das Makefile selber?
hmm, der Fehler ist aber oft recht leicht in den Makefile.am zu finden.
> RPMs habe ich bisher tatsächlich nicht gebaut, das empfand ich bei der
> geringen Zahl der verwalteten Systeme einfach nicht zweckmäßig. Aber
> daß ein Installationsvorgang nicht wie gewünscht funktioniert kenne
> ich zur Genüge. In meiner Erfahrung bereiten allerdings
> selbstgeschriebene Makefiles mit fehlerhaften Annahmen z.B. bezüglich
> /usr/bin/install genauso viele Probleme und sind durchaus nicht einmal
> in der Mehrzahl der Fälle einfacher zu lösen, als selbst eine lokale
> Variante des Makefiles fast von Grund auf zu erstellen.
Jup!
Bei meinem LFS war am Anfang nicht viel mehr als sh und init in /bin.
Hui, hatten da viele Installscripts (Nein, nicht die von Autoconf :)
hardgecodede Pfade und ich durfte jedem Menge Symlinks erstellen.
Gruß, Martin!
--
2 Pi || ! 2 Pi -> == ?
Gunnar Ritter
> Das Erstellen von portablen sh-Skripten ist nur leider alles andere als
> einfach,
Auf dem trivialen Niveau wie oben schon. Das Erstellen von
portablen autoconf-Skripten ist eh nicht einfacher, wie man
an den vielen total kaputten Exemplaren erkennen kann.
Dinge werden dann portabel, wenn der Programmierer hinreichend
Erfahrung hat. Dann kann er auch prima portable Shell-Skripte
schreiben. Sonst hilft die portable autoconf-Grundfunktionalität
auch nichts, weil das Projekt selbst sowieso nicht portabel ist.
> Für die angesprochenen einfachen Projekte kann autoconf
> einem das meist ganz ersparen.
Wofür es dann nur ungefähr das hundertfache an Laufzeit und
Skriptumfang benötigt. Ich bin schwer beeindruckt von dieser
Ersparnis.
>> > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
>> > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
>> > bleiben und ausführlicher output in config.log)
>> Genau solche Checks sind es, die einen zur Weißglut bringen,
>> wenn sie nicht funktionieren. Dann hast Du es nämlich nicht
>> mehr nur mit einer Handvoll Zeilen Shell zu tun wie oben.
>> Hast Du noch nicht erlebt, ja? Dann schweige einfach dazu.
> Nur sind eben diese Resultate genau das, was das configure-Skript ohne
> KI-Erweiterung feststellen kann.
Du hast das nicht verstanden. Das Problem besteht dann, wenn
ein configure-Skript zu Unrecht feststellt, daß etwas nicht
funktioniert. Die meisten dieser Checks sind total überflüssig.
Man kann die Software bauen und sehen, ob es funktioniert. Und
wenn es dann nicht funktioniert, kann man sich darum kümmern.
So checkt erst autoconf, ob es funktioniert, was keine Aussage
darüber sein muß, ob es bei den eigentlichen Quellen funktioniert
oder nicht funktioniert. Speziell nicht, wenn der Check von
Deppen des Typs «Oh weh, Shell ist mir zu kompliziert, ich nehme
autoconf» fabriziert wurde. Der einzige Effekt dieser Methode ist
der, daß ich noch an einer weiteren Stelle Code zum Laufen bringen
muß. Ich bin auch von diesem Vorzug von autoconf schwer beeindruckt.
>> > 2. einfacheres Handling von Systemen, die sich gegen die Portierung
>> > von Software wehren (nicht vorhandene Libraryfunktionen etc.)
>> autoconf hilft Dir da nicht wirklich weiter. Die Funktionen
>> darfst Du alle selber schreiben, autoconf führt nur ein paar
>> Checks durch. Checks von der Art, wie Du sie oben gerade gesehen
>> hast, offensichtlich ohne sie zu verstehen. Libraryfunktionen
>> sind wirklich trivial zu checken, mit oder ohne autoconf.
> Ich meinte auch sowohl autoconf als auch automake, denn beide sind ein
> geprüftes Gespann für conditional compilation, um fehlerhafte oder
> fehlende Funktionen im BS zu ersetzen.
Quatsch. Die gesamte Leistung von autobloat in diesem Bereich besteht
darin, ein Define bereitzustellen. Genau das hat der Code aus meinem
vorletzten Posting auch getan.
> Und wenn man sich ein wenig umsieht, findet man durchaus einige
> fertige Lösungen, schon das eher magere "Autoconf Macro Archive"
> enthält viele brauchbare Ansätze.
ROTFL
Lies: Und selbst, wenn man sich lange umgesehen hat, um Deine
Position zu halten, findet man nur das «Autoconf Macro Archive»,
das nicht mal für Trivialitäten wie strcasecmp() mehr als einen
Ansatz bereithält.
Gunnar
Gunnar Ritter
> Felix von Leitner <usenet-...@fefe.de> writes:
>> Dafür sind die generierten Makefiles absolut unleserlich, geradezu eine
>> Zumutung. Es ist außer für automake-Entwickler nicht zumutbar, einen
>> Bug zu diagnostizieren, wenn er auftritt. Und das Ändern der .am-Datei
>> führt im Regelfall dank ständiger Inkompatibilitäten zwischen
>> automake-Versionen zu völlig kaputten Dateien und einem direkt auf die
>> Schnauze fallenden Build.
> Wie jemand anderes bereits schrieb, ist man auch selbst Schuld, wenn
> man versucht ein Makefile.am für mehrere automake-Versionen zu
> schreiben.
Genau deshalb ist automake ja unbrauchbar! Denn das bedeutet,
daß Du Dir für jedes Paket erst die passende automake-Version
besorgen mußt, wenn Du am Buildprozeß etwas ändern willst.
Gunnar
Gunnar Ritter
> Typisches GNU-Paket: GNU fileutils. Die größten 10 Dateien sind:
> [...]
> -rw-r--r-- 1 leitner users 249223 Apr 2 2001 lib/regex.c
Und weißt Du, wofür sie das brauchen? Einzig und allein um
festzustellen, ob Du bei «rm -i» usw. die lokale Version von
'y' oder 'n' eingegeben hast!
Gunnar
Rainer Weikusat
> > > 1. Bessere, weil generische, Diagnosemeldungen (einfache direkte
> > > Ausgabe wie "checking for openssl: failed", um beim Beispiel zu
> > > bleiben
> >
> > Typischerweise bedeutet 'falscher Pfad hartkodiert'.
>
> Ist es also besser, dem Anwender durch eine dementsprechende Meldung
> einen eventuell irreführenden Hinweis zu geben?
Das ist ein 'eventuell irreführender Hinweis', denn man kann ihm nicht
entnehmen, ob das Skript oder die fehlende Bibliothek gemeint sind.
Es gibt Leute, die (für openssl oder Kerberos 5 zum Beispiel)
/usr/local/... in configure.in direkt eintragen. Findet configure da
nichts, bricht der Vorgang mit einem Fehler ab. Auf einem System, zu
dem OpenSSL normalerweise gehört (*BSD, Debian etc) wäre das unnötig,
weil ein simples Testprogram genügt hätte, um die benötigten Dateien
zu finden. Ggf gibt es --with-ssl[-include-[dir]]-Optionen, die auch
in der überwiegenden Zahl der Fälle eine Auswirkung haben (aber wenn
viele Leute unabhängig voneinander Programmteile entwicklen, zB als
Plugins, garantiert irgendwo nicht), andernfalls muß man das Skript
ändern. Wo liegt der Vorteil gegenüber einem Hinweis, welche
systemabhängigen Annahmen im Makefile gemacht werden und wo man ggf an
sie herankommt?
> > Kannst Du Dir vorstellen, warum ich folgendes Skript benutze?
[micro-build-script]
> Natürlich kann ich mir das vorstellen, es erspart Schreibarbeit und
> Tippfehler
Also nein.
> nicht in jedem Fall die Aufgabe von autoconf. Exakt dieses Beispiel
> würde in autoconf durch
>
> #!/bin/sh
> CFLAGS="-I/usr/local/openssl-0.9.7/include" \
> LDFLAGS="-L/usr/local/openssl-0.9.7/lib" /path/to/configure
>
> realisiert. Da kann ich jetzt nicht genau erkennen, in welcher Weise
> beides differiert.
ZB darin, daß ich ein funktionierendes binary bekomme (Nutzung von
libtool sollte strafrechtlich verfolgt werden ...).
Rainer Weikusat
> > Allerdings um den Preis hochkomplexer und unlesbarer Makefiles.
>
> Jein, was ich da an handverzapftem gesehen habe, war auch nicht gerade
> berauschend. Ich glaube nicht, daß Makefiles auf Dauer durch
> kristallklare Struktur glänzen können, dazu wird die Zahl der
> Eventualitäten mit der Zahl der unterstützten Systeme einfach zu
> groß.
Du wolltest jetzt nicht gerade sagen, daß ein komplexeres Problem ein
komplexeres Programm erfordert, nein? Im 08/15-Fall, dh 'übersetze
alles und linke es einschließlich dieser oder jener Bibliothek
hinterher zusammen' kommt man mit simplen Makefiles aus.
> In meiner Erfahrung bereiten allerdings
> selbstgeschriebene Makefiles mit fehlerhaften Annahmen z.B. bezüglich
> /usr/bin/install genauso viele Probleme und sind durchaus nicht einmal
> in der Mehrzahl der Fälle einfacher zu lösen, als selbst eine lokale
> Variante des Makefiles fast von Grund auf zu erstellen.
Worauf beziehst Du dich? Die aufwendigsten Beispiele, die mir
einfielen, wären ISC-dchpd und nethack und in beiden Fällen war das im
Vergleich zu der Zeit, die ich schon in auto*-Dateien nach obskuren
Zeichenkombinationen gesucht habe, vernachlässigbar.
> > Im übrigen überlasse ich den job des "make uninstall" lieber rpm oder
> > dpkg, schon deswegen weil ich die source-trees nicht ewig herumliegen
> > lassen will.
>
> In meiner Wahrnehmung ist das "Verschwenden" von Speicherplatz
> billiger als meine Zeit jedesmal für das Entwickeln von
> OS-spezifischen Paketen aufzuwenden (wir sprechen hier von der
> Vielzahl fremder Software und nicht den tendenziell wenigeren eigenen
> Projekten?)
Mit
a) configure ist überflüssig
oder
b) configure ist fehlerhaft
hat man >90% aller mir bekannten praktischen Anwendungsfälle
erschlagen.
Uwe Ohse
>Und weißt Du, wofür sie das brauchen? Einzig und allein um
>festzustellen, ob Du bei «rm -i» usw. die lokale Version von
>'y' oder 'n' eingegeben hast!
in diesem Stück Code, daß die Eingabe eines falschen Zeichens wie einen
Fehler von regcomp behandelt?
Ja, das ist ein besonders beeindruckendes Machwerk.
Gruß, Uwe
Felix von Leitner
Gunnar Ritter
[fileutils]
>>Und weißt Du, wofür sie das brauchen? Einzig und allein um
>>festzustellen, ob Du bei «rm -i» usw. die lokale Version von
>>'y' oder 'n' eingegeben hast!
> in diesem Stück Code, daß die Eingabe eines falschen Zeichens wie einen
> Fehler von regcomp behandelt?
Moment. regcomp() bekommt «^[yY]» und sie checken dann mit regexec(),
ob Deine Eingabe dazu paßt. Einen Fehler bei regcomp() kann es also
eigentlich nur geben, wenn die REs aus den Message-Files defekt sind
(es sei denn, ihr Bloat läßt ihnen nicht mehr genügend Speicher).
Was ich so zum Kotzen finde ist, daß es sich dabei allesamt um
Pattern handelt, die man z. B. mit dem eingebauten fnmatch() (230
Zeilen) oder einer ähnlich simplen Funktion hätte checken können.
Aber stattdessen packen sie über 8000 Zeilen eigenen RE-Code drauf.
Und es muß natürlich ihr eigener RE-Code sein, denn dem vom System
kann man ja nicht mal für so simple Pattern trauen.
Und dann bekommen wir hier von den autobloat-Junkies erzählt, daß
man damit so toll «fehlerhafte oder fehlende Funktionen» ersetzen
könne. Ich bin begeistert.
Gunnar
Gunnar Ritter
> Uwe Ohse <u...@ohse.de> wrote:
> [fileutils]
>>>Und weißt Du, wofür sie das brauchen? Einzig und allein um
>>>festzustellen, ob Du bei «rm -i» usw. die lokale Version von
>>>'y' oder 'n' eingegeben hast!
>> in diesem Stück Code, daß die Eingabe eines falschen Zeichens wie einen
>> Fehler von regcomp behandelt?
> Moment. regcomp() bekommt «^[yY]» und sie checken dann mit regexec(),
> ob Deine Eingabe dazu paßt. Einen Fehler bei regcomp() kann es also
> eigentlich nur geben, wenn die REs aus den Message-Files defekt sind
Ach so, Mißverständnis. Du meinst, daß sie bei einem Fehler von
regcomp() denselben Wert zurückgeben, wie wenn Du weder «ja» noch
«nein» geantwortet hast. Stimmt. Das ist in der Tat ein weiterer
Anlaß zum Kotzen, daß ihre Bloat-Funktion auch noch ein kaputtes
API hat.
Nur ist es an dieser Stelle egal, ob Du «nein» oder «foo» eingibst,
weil für rm laut POSIX nur zustimmende Antworten zählen; «falsche»
Zeichen gibt es da eigentlich nicht. Deshalb hatte ich nicht recht
verstanden, worauf Du hinauswolltest.
Gunnar
Felix von Leitner
> > Typisches GNU-Paket: GNU fileutils. Die größten 10 Dateien sind:
> > [...]
> > -rw-r--r-- 1 leitner users 249223 Apr 2 2001 lib/regex.c
> Und weißt Du, wofür sie das brauchen? Einzig und allein um
> festzustellen, ob Du bei «rm -i» usw. die lokale Version von
> 'y' oder 'n' eingegeben hast!
Leute, vergeßt fileutils.
Jetzt gibt es GNU coreutils.
Man kompiliert es durch, sagt "make check", und er _kommt_ nicht mal
soweit, die Testsuite aufzurufen, weil er schon abbricht, bevor er
überhaupt das erste Test-Programm kompiliert und aufgerufen hat!
Wenn man aber manuell nach test geht und make check sagt, dann fummelt
er eine Weile herum und die ersten 100 oder so Tests laufen sogar durch.
Man sollte denken, daß das mal jemandem aufgefallen wäre, bevor sie das
auf den FTP-Server tun...?
Felix
Uwe Ohse
>Man kompiliert es durch, sagt "make check", und er _kommt_ nicht mal
>soweit, die Testsuite aufzurufen, weil er schon abbricht, bevor er
>überhaupt das erste Test-Programm kompiliert und aufgerufen hat!
../configure: test: =: unary operator expected
checking for _LARGEFILE_SOURCE value needed for large files... no
btw: "yes" wäre richtig gewesen. linux, glibc-2.2.5, gcc-3.2.
>Wenn man aber manuell nach test geht und make check sagt, dann fummelt
>er eine Weile herum und die ersten 100 oder so Tests laufen sogar durch.
>Man sollte denken, daß das mal jemandem aufgefallen wäre, bevor sie das
>auf den FTP-Server tun...?
alpha.gnu.org ist genau für solche kaputten Sachen gedacht.
Gruß, Uwe
Uwe Ohse
>Und dann bekommen wir hier von den autobloat-Junkies erzählt, daß
>man damit so toll «fehlerhafte oder fehlende Funktionen» ersetzen
>könne. Ich bin begeistert.
klar. Auf welchen Systemen, denen reg* fehlt, bekommt man ein MB
große configure-Scripte durchgenudelt?
-rwxr-xr-x 1 uwe users 1035595 Jul 20 16:00 \
fileutils-4.1.11/configure
ok, fast 13 K fehlen noch bis zum MB, aber das bekommen die Entwickler
bestimmt noch hin. Ich hab' da allergrößtes Ver^WMißtrauen, schließlich
haben die sh-utils das ja auch geschafft.
Gruß, Uwe
Thomas Jahns
> Thomas Jahns <Thomas...@epost.de> writes:
> > > Allerdings um den Preis hochkomplexer und unlesbarer Makefiles.
> >
> > Jein, was ich da an handverzapftem gesehen habe, war auch nicht gerade
> > berauschend. Ich glaube nicht, daß Makefiles auf Dauer durch
> > kristallklare Struktur glänzen können, dazu wird die Zahl der
> > Eventualitäten mit der Zahl der unterstützten Systeme einfach zu
> > groß.
>
> Du wolltest jetzt nicht gerade sagen, daß ein komplexeres Problem ein
> komplexeres Programm erfordert, nein? Im 08/15-Fall, dh 'übersetze
> alles und linke es einschließlich dieser oder jener Bibliothek
> hinterher zusammen' kommt man mit simplen Makefiles aus.
Nur ist es eben ein Unterschied, ob man diese Komplexität selbst per
Hand verwalten muß, oder das an die autotools delegieren kann.
> > In meiner Erfahrung bereiten allerdings
> > selbstgeschriebene Makefiles mit fehlerhaften Annahmen z.B. bezüglich
> > /usr/bin/install genauso viele Probleme und sind durchaus nicht einmal
> > in der Mehrzahl der Fälle einfacher zu lösen, als selbst eine lokale
> > Variante des Makefiles fast von Grund auf zu erstellen.
>
> Worauf beziehst Du dich? Die aufwendigsten Beispiele, die mir
> einfielen, wären ISC-dchpd und nethack und in beiden Fällen war das im
> Vergleich zu der Zeit, die ich schon in auto*-Dateien nach obskuren
> Zeichenkombinationen gesucht habe, vernachlässigbar.
Na also ich habe z.B. mich einmal geärgert, als ich prngd auf
vernünftiges Installieren (in IRIX 5.3) und eine ordentliche
Optimierung trimmen mußte. Natürlich war das vom intellektuellen
Aufwand her nicht der Rede wert, aber da es dennoch etwas gedauert
hat, während die entsprechenden Einstellungen in autoconf-Paketen
eigentlich immer in gleicher Weise und schnell vorzunehmen sind, hat
es mich schon geärgert.
Es ist nicht die Tatsache, daß die Problemchem stets schwieriger zu
beseitigen wären, das ist nicht der Fall, die mich stört, sondern daß
es jedes mal anders geht, wenn sich da einer eine eigene Lösung
überlegt, die ich erstmal neu durchblicken muss. Die autotools
hingegen sorgen für meist gleiche Struktur und die Fehler sind meist
auch noch die gleichen.
> > > Im übrigen überlasse ich den job des "make uninstall" lieber rpm oder
> > > dpkg, schon deswegen weil ich die source-trees nicht ewig herumliegen
> > > lassen will.
> >
> > In meiner Wahrnehmung ist das "Verschwenden" von Speicherplatz
> > billiger als meine Zeit jedesmal für das Entwickeln von
> > OS-spezifischen Paketen aufzuwenden (wir sprechen hier von der
> > Vielzahl fremder Software und nicht den tendenziell wenigeren eigenen
> > Projekten?)
>
> Mit
>
> a) configure ist überflüssig
>
> oder
>
> b) configure ist fehlerhaft
>
> hat man >90% aller mir bekannten praktischen Anwendungsfälle
> erschlagen.
Und meine Erfahrung ist eben die, daß ich erstens Fehler durch
falschen Einsatz von autoconf schneller und leichter ausbügeln kann
und ich zweitens durch configure sehr viel leichter einen
Installationsort und andere Parameter des build kontrollieren kann.
Thomas Jahns
> Was ich so zum Kotzen finde ist, daß es sich dabei allesamt um
> Pattern handelt, die man z. B. mit dem eingebauten fnmatch() (230
> Zeilen) oder einer ähnlich simplen Funktion hätte checken können.
> Aber stattdessen packen sie über 8000 Zeilen eigenen RE-Code drauf.
> Und es muß natürlich ihr eigener RE-Code sein, denn dem vom System
> kann man ja nicht mal für so simple Pattern trauen.
Und Du paßt auch immer schön artig auf, daß die Pattern so einfach
bleiben, und paßt dann bei Bedarf punktgenau an? Ich habe
zugegebenermaßen keine Ahnung, wie kompliziert die Sache z.B. bei
Japanisch wird. Wenn aber irgendwann die Entscheidung, wie vorsichtig
man sein will, ansteht, kann ich mir gute Gründe für einen eher
konservativen Standpunkt vorstellen.
> Und dann bekommen wir hier von den autobloat-Junkies erzählt, daß
> man damit so toll «fehlerhafte oder fehlende Funktionen» ersetzen
> könne. Ich bin begeistert.
Denn der Sinn ist eben, nur für ein API zu programmieren. Ich weiß
zugegebenermaßen nicht, wo regexec/regcomp fehlen/fehlerhaft sind,
aber daß die fileutils einen test enthalten, ausreichend "gute"
Implementierungen zu identifizieren, ist für mich ein Hinweis, daß es
wohl auch schlechte gibt.
Thomas Jahns
> > > Thus spake Thomas Jahns (Thomas...@epost.de):
> > > Gegen autoconf an sich ist nicht viel zu sagen, außer daß bei einem
> > > typischen Projekt configure und Freunde 70% des Tarballs ausmachen.
> > Da handelt es sich dann aber um wirklich kleine Pakete,
>
> Nein.
Bitte ein taugliches Gegenbeispiel, s.u.
> > und daß das nicht bedeutet, daß der Entwickler tatsächlich 70% seiner
> > Zeit für das Schreiben dieser Skripte/Makefile.in's aufgewandt hat ist
> > wohl auch klar.
>
> Die Zeit des Entwicklers geht mir _vollständig_ am Arsch vorbei.
Dem Entwickler aber vielleicht nicht.
> Ich als Enduser ziehe mir diesen Bullshit und zahle für die Bandbreite
> und den Lagerplatz. Der Anbieter zahlt normalerweise auch für seine
> Bandbreite, umso weniger verzeihlich ist es, wenn er da unnötig
> rumbloatet.
Es ist wohl ein wenig übertrieben, vom Entwickler zu verlangen, den
source-tree exclusiv auf deine Bedürfnisse abzustimmen.
> Typisches GNU-Paket: GNU fileutils. Die größten 10 Dateien sind:
>
> -rwxr-xr-x 1 leitner users 656917 Apr 29 2001 configure
> -rw-r--r-- 1 leitner users 249223 Apr 2 2001 lib/regex.c
> -rw-r--r-- 1 leitner users 223087 Feb 22 1998 ChangeLog-1997
> -rw-r--r-- 1 leitner users 215535 Apr 29 2001 ChangeLog
> -rw-r--r-- 1 leitner users 205887 Apr 21 2001 doc/texinfo.tex
> -rw-r--r-- 1 leitner users 169243 Apr 29 2001 doc/fileutils.info
> -rw-r--r-- 1 leitner users 133836 Apr 29 2001 po/es.po
> -rw-r--r-- 1 leitner users 124073 Apr 29 2001 aclocal.m4
> -rw-r--r-- 1 leitner users 111767 Apr 23 2001 doc/fileutils.texi
> -rw-r--r-- 1 leitner users 107647 Apr 29 2001 po/fr.po
>
> Ganz großartig. Überhaupt: 650k configure-Script?! Mein erster PC
> hatte weniger RAM als GNU hier in Form eines Scripts rauskloppt!
Insgesamt sind wohl trotzdem 1200k von 8.3M (mit du auf i386-reiserfs
unter SuSE Linux ermittelt) des fileutils-Pakets nicht nahe genug an
den verlangten 70% (die i18n-Dateien zählen wohl nicht zum autotools
"Bloat"). Und das, obwohl ein so vielfach verwendetes Paket wie die GNU
fileutils sicherlich auf alles portiert worden ist, was nicht
rechtzeitig auf den Bäumen war, demnach also ein eher atypisches
Beispiel, wenn es auch das mit den autotools erreichbare sicherlich
sehr gut demonstriert.
> > > ROTFL.
> > > Generische Fehlermeldungen, my ass.
> > > "checking whether your gcc installation is sane: no".
> > > Sehr hilfreich, das.
> > Wie ich schon schrieb, sind die Fehlermeldungen aber meist gleich, also
> > vertraut.
>
> Das hilft mir ungemein, wenn mir schon bei den letzten fünfzehn
> vim-Versionen diese Fehlermeldung auf den Fuß gefallen ist, weil die
> vim-Autoren finden, daß Cross-Compiler zu selten sind, als daß man sie
> unterstützen sollte.
Du hast den Autoren nicht zufällig einen patch zugesandt? Oder
erwartest Du von den Autoren, eine Konfiguration zu unterstützen und
testen, die sie anscheinend gar nicht vorliegen haben, ohne Hilfe von
jemandem zu erhalten, der sie nutzt?
> > Und diese Ausgabe ist die kürzeste und dennoch richtige
> > Möglichkeit.
>
> Bullshit.
Da hätte ich wohl "unter der Annahme, daß das zugrundeliegende
configure.in/.ac nicht fehlerhaft ist" dazuschreiben sollen. Nicht,
daß Du nicht von vornherein hättest erwähnen können, welchen Fehler Du
meinst.
> > Schreib mal eine ausführliche Fehlermeldung im voraus, die den
> > tatsächlich vorliegenden Sachverhalt besser beschreibt, als die
> > Fehlermeldungen in config.log.
>
> Der Sachverhalt ist, daß ich vim cross-compilen wollte.
> NATÜRLICH ist meine Compiler-Umgebung sane.
Nur ist das in diesem Fall ein Fehler im zugrundeliegenden
configure-Skript. Vom configure-Skript zu erwarten, daß es Fehler in
seinem eigenen Code erkennt, ist wohl etwas hoch gegriffen. Und da der
obige Einzeiler Dir ermöglicht schnell die tatsächlichen
Fehlermeldungen in config.log einzusehen, liefert Dir diese Umgebung
alles, um einen Patch an die Entwickler zusammenzustellen.
> > > Oder hunderte von Folgefehlern. Typische autoconf-Scripte machen am
> > > Anfang irgendwas falsch und fallen danach bei allen weiteren Tests auf
> > > die Schnauze und detecten dann so tolle Sachen wie fehlendes unistd.h,
> > > fehlendes stdio.h, kein openssl, kein libpng etc.
> > Das ist ja wohl auch bei fast allen compilern so, daß meist nur die erste
> > Fehlermeldung wirklich sinnvoll zur Fehlersuche herangezogen werden
> > kann, also wohl kaum ein überraschender Umstand. Tatsächlich wäre es
> > wohl besser, wenn das configure-Skript sich nach solch fatalen
> > Befunden sofort beendet und das kann man auch leicht implementieren.
>
> Nur tut GNU configure den Bullshit dann in einen Cache, wo man ihn
> dann manuell austragen muß, nachdem man die Bugs in configure fixen
> mußte.
Der Sinn des Cache liegt aber auch nun darin, Situationen wie den gcc
zu unterstützen, wo zur Kompilation mehrere sub-configure
ablaufen. Wenn configure geändert wird, so ist es wohl offensichtlich,
daß der cache der Vorgängerversion gelöscht werden sollte.
> > > autoconf ist nur in den Händen von echt fähigen Experten hilfreich.
> > > Bei allen anderen macht es mehr Ärger als es einspart.
> > >
>
> Das mit dem Quoten üben wir aber noch mal...
Da wollte ich ursprünglich etwas erwidern, habe es dann aber
gelassen. Ich bitte 1000mal um Verzeihung, den Absatz in der
Endkorrektur versehentlich stehen gelassen zu haben. Eine ganz wilde
Sache das, ich muß wohl fürchten, daß demnächst die Netiquette-Polizei
bei mir vorbeischaut.
> > > Bullshit. Gerade solche Systeme werden nur unterstützt, wenn der
> > > Softwareautor so ein System schon mal gesehen hat und weiß, wie man auf
> > > sowas arbeitet. Typische Mülli-autoconf-Systeme benutzen bashismen im
> > > Makefile oder hard-coden Pfade ala /usr/bin/gmake. Alles schon gehabt.
Um hier noch einmal anzusetzen: Ich habe nicht behauptet, daß die
autotools fehlerfreie Programme erzwingen, nur daß sie es erleichtern,
fehlerarme Konstruktionen von anderen zu nutzen, die vornehmlich den
Vorteil haben, weniger fehlerhafte Annahmen zu enthalten, als daß was
man sich selbst von Grund auf überlegt. Das ist eben meine Erfahrung
und muß sich nicht mit Deiner decken.
Ich kenne leider kein Mittel gegen Softwarefehler, daß nicht von DAUs
ausgehebelt werden könnte, genauso wie die ISO 9000 leider auch nur
sicherstellt, im Zweifelsfalle gleichbleibend schlechten Mist zu fertigen.
> > Wenn aber nur eine Funktion fehlt (z.B. vsnprintf(3)) dann ist mit den
> > autotools verhältnismäßig leicht, das in einer bei allen Projekten,
> > die autotools und die fehlende Funktion verwenden, gleichen Weise
> > einzubauen.
>
> ROTFL, guter Plan!
> Wir bloaten am besten jedes einzelne Softwarepaket mit einer halben
> libc-Implementation auf, damit die Hersteller von kaputten Müll-Unixen
> keine Notwendigkeit haben, ihren Schrott zu fixen. Toller Plan.
> Ich kann förmlich vor mir sehen, wie gut der funktioniert. Man sieht ja
> schon, wie toll er in den letzten Jahren funktioniert hat. Gar nicht.
Dir kommt nicht zufällig in den Sinn, daß dabei auch Systeme
unterstützt werden, deren Hersteller den Support eingestellt haben
(oder es nur eine Frage der Zeit ist, bis der Hersteller
verschwindet), die aber trotzdem noch Verwendung finden, soll ja
vorkommen. Auch Leute, die ihre Systeme gar nicht fixen können (Bug
nicht gravierend genug, um die Downtime zu rechtfertigen) werden dafür
im Zweifelsfalle dankbar sein.
> > Ich nehme da als Beispiel mal die gettext/libintl-Unterstützung:
> > überall gleich (und leider auch lange fehlerhaft), für den einzelnen
> > Projekt-Autor aber mit verschwindend geringem Aufwand verfügbar.
>
> Dafür sind die autoconf-Deppen häufig zu dämlich, --disable-nls
> anzubieten.
Das Thema, daß nicht angeboten wird, was nicht auch (von hinreichend
Vielen) verlangt wird habe ich ja schon oben angesprochen.
> > Daß Leute, die vpath-builds nie ausprobiert haben, oder in $srcdir
> > feste Pfade ablegen, so daß man das Oberverzeichnis von build- und
> > source-Tree nicht verschieben kann, stelle ich gar nicht in Abrede.
> > Aber die gleichen Leute sind nach meiner Einschätzung bei der
> > Neuerfindung des Rades durch Erstellen eines eigenen Systems für den
> > build- und Installationsprozess auch nicht weniger, sondern mehr in
> > Gefahr einen Alptraum für andere zu produzieren.
>
> Ach was. Der absolute Ultra-Albtraum sind Pseudo-Experten wie Herr
> Schily, die sich auch noch im Recht wähnen, wenn sie irgendwelche
> untransparenten Buildsysteme bauen, die am Ende auch nur autoconf
> aufrufen, aber zu dämlich sind, dem User die üblichen autoconf-Optionen
> anzubieten.
Da ich selbst star als Beispiel mißratener (IMHO) build-Systeme
angeführt habe sind wir uns hier ja einig.
> /opt/schily. Ich könnte kübelweise kotzen über sowas.
Die Fehler von Herrn Schily nicht die der autotools sind ist auch klar oder?
> > > Dafür sind die generierten Makefiles absolut unleserlich, geradezu eine
> > > Zumutung. Es ist außer für automake-Entwickler nicht zumutbar, einen
> > > Bug zu diagnostizieren, wenn er auftritt. Und das Ändern der .am-Datei
> > > führt im Regelfall dank ständiger Inkompatibilitäten zwischen
> > > automake-Versionen zu völlig kaputten Dateien und einem direkt auf die
> > > Schnauze fallenden Build.
> > Wie jemand anderes bereits schrieb, ist man auch selbst Schuld, wenn
> > man versucht ein Makefile.am für mehrere automake-Versionen zu
> > schreiben.
>
> Klar, nicht das völlig kaputte Schrott-Müll-Scheiß-Kack-Utility
> "automake" ist schuld daran, daß es die Welt mit Albtraum-Müllcode
> zupflastert, sondern die Programmierer, die versuchen, zu mehreren
> Versionen kompatibel zu sein. Merkst du eigentlich noch was? Die
> Herstellung von Kompatibilität ist die Hauptaufgabe von Programmierern!
Nur dann, wenn Kompatibilität auch die Agenda ist. Normalerweise ist
die Hauptaufgabe ein funktionstüchtiges, fehlerarmes Produkt und
Kompatibilität in 99,999% der Fälle ein notwendiges Kriterium für
funktionstüchtig.
Im Falle autotools sind die Übergänge von einer Version zur nächsten
allerdings so gestaltet, daß sie nur wenige Anpassungen erfordern.
> > > Das Gegenteil ist der Fall. Für den typischen Admin sind automake-Bugs
> > > schwieriger zu diagnostizieren als RAM-Fehler. Solche Leute fummeln ein
> > > bißchen rum, verkacken ihre Installation vollständig, und ziehen sich
> > > dann ein Binary-Paket.
> > Meine diesbezügliche Erfahrung ist (mit Ausnahme solch grauenhafter
> > Monster wie KDE oder Gnome) eine andere.
>
> Klar, für die funktionierende Software ist automake toll, außer man
> versucht, die Scripte zu lesen. Diese Fälle deklarierst du einfach zu
> Monster-Software und kommst dann mit der grandiosen Aussage, daß das nur
> bei Monster-Software schlecht ist. Ganz tolle Aussage, das.
Daß Gnome und KDE ein Problem bezüglich des Skalierens mit der Zahl
der Entwickler haben, ist ein Aspekt, der sich durchaus nicht nur in
den Makefile.am äußert, sondern in den Quellen insgesamt. Wie jemand
anderes bereits anmerkte, ist es durchaus nicht immer nötig, den Bug im
Makefile zu suchen, wenn man ihn auch gut in Makefile.am finden kann,
das nicht nur leichter als das produzierte Makefile sondern auch
leichter als ein handgeschriebenes Makefile zu lesen sein sollte.
[...]
> > Das vornehmlich Bequemlichkeit und Arbeitsteilung sowie
> > Sicherheitsbedenken diesen Umstand befördern könnten, kommt Dir nicht
> > in den Sinn?
>
> Sicherheitsbedenken?!
> Das ist ja wohl die dämlichste Begründung, auf Binärpakete umzusteigen,
> die ich je gehört habe. Du mußt ja wirklich unglaublich stoned sein.
> Darf ich fragen, was für Stoff du da gerade zu dir nimmst?
Tja, ganz einfach. Es gibt eben Leute, die warten können, bis das
geflickte Paket beim Distributor erhältlich ist (daß man da nicht
gerade auf Sun mit seinem Linux warten sollte ist ein anderer Aspekt)
und den Dienst z.B. einfach einen Arbeitstag abstellen. Für viele mag
das ein völlig inakzeptabler Zeitraum sein und die müssen dann in der
Tat selbst kompilieren, aber für die Mehrzahl zumindest der
Linux-Nutzer ist die erste Alternative anscheinend
attraktiver. Zumindest mir erscheint das plausibel.
> > Das Portieren von einer Plattform auf eine einzelne andere ist wohl
> > immer einfacher, als für ein API auf mehreren Plattformen zu
> > schreiben und gleichzeitig das API selbst (teilweise) auf allen
> > unterstützten Plattformen zur Verfügung zu stellen. Die Probleme, die
> > die autotools zu lösen versuchen, sind da eine Nummer größer als von
> > BSD nach Solaris. Denn die einfache Portierung durch Anpassen des
> > Kern-Programmcodes an die verschieden System-APIs führt fast
> > unweigerlich zum Fork in verschiedene Entwicklungsstränge oder
> > Alpträume aus #ifdef-Schachtelungen (womit ich nicht unterstelle, daß
> > Du so vorgegangen bist).
>
> BSD und Solaris _sind_ verschiedene APIs! Solaris ist System V!
Und genau das meinte ich auch. Aber es sind eben nur _zwei_. Die
autotools zielen auf deutlich mehr Plattformen (Win32 und VMS kommen
mir in den Sinn) als mögliche Ziele. Im Vergleich dazu sind BSD und
Solaris noch recht ähnlich.
> Weißt du eigentlich überhaupt irgendwas über die Themen, über die du
> hier herumschwadronierst?
Zumindest ist Dein konsequentes Mißverstehen meiner Äußerungen auch
nicht gerade hilfreich.
> Meine Güte, ich ziehe Leute wie dich in letzter Zeit offenbar irgendwie
> an. Ist ja fürchterlich.
Daß jemand, der wie Du so grotesk einseitige Positionen vertritt,
Widerspruch erntet ist wohl nur natürlich und verständlich.
> > > Die auto*-Pakete mit einem anständigen README/INSTALL kann man an zwei
> > > Fingern abzählen.
> > Du wärest nicht so freundlich, auch zu erklären, was mit anständig
> > gemeint ist? Nicht daß ich keine Vorstellung hätte, aber die muß ja
> > nicht deckungsgleich mit Deiner sein.
>
> Ein README-File sollte beschreiben, was das Paket tut, warum man es
> installieren will, welche Alternativen aus welchen Gründen schlechter
> sind, und wer der Autor ist und wie man Bugs melden kann. Außerdem
> sollte es eine rudimentäre Einführung beinhalten, wie man mit der
> Software umgeht.
Welche Alternativen bestehen, ist für den Autor zum Zeitpunkt des
Schreibens nicht immer einfach zu klären, hier in die Zukunft zu
extrapolieren ist dann wohl nicht einfacher (Alternativen müssen
nämlich nicht schlechter bleiben), eher schon sollte der Autor
versuchen zu erklären, welche(s) Paket(e) er ersetzen will. Die
rudimentäre Einführung sähe ich wohl meist lieber in der
EXAMPLES-section der manpage, aber das ist wohl eine
Geschmacksfrage. Ansonsten stimmen unsere Vorstellungen wohl überein,
jedoch kann ich nicht nicht von so vielen Paketen berichten, die sich
grob "unanständige" READMEs leisten.
> Ein INSTALL-File sollte beschreiben, wie man die Software installiert,
> welche Konfigurationsoptionen es gibt, wie man die Software wieder los
> wird, und was für Compile Time Einstellungen es gibt, von denen man
> wissen muß.
Nur leider verlangt das, das README zusätzlich zu den direkt durch
configure --help erhältlichen Erläuterungen anzupassen. Ich finde man
kann jedem selbst überlassen, ob er diese Arbeit übernehmen will,
genauso, wie ich es toleriere, nur info-Dateien zu pflegen, denn
obwohl ich darüber nicht begeistert bin, kann ich die Entscheidung
dennoch verstehen.
> Der meiste auto*-Müll liefert das generische INSTALL-File von autoconf
> mit. Das ist absolut überflüssige Platzverschwendung und eine
> Frechheit gegenüber dem Enduser.
Wenn Dir ein Weg einfällt, vorherzusagen, bei welchem Paket dem
Einsteiger zuerst das GNU build-system begegnet, bin ich gerne bereit,
die Datei aus allen anderen Paketen zu eliminieren. Obwohl ich nicht
meine, daß die 8k (3 nach Komprimierung) ein gigantischer Gewinn
wären.
Thomas Jahns
> Das ist ein 'eventuell irreführender Hinweis', denn man kann ihm nicht
> entnehmen, ob das Skript oder die fehlende Bibliothek gemeint sind.
Nun sind z.B. unter IRIX sehr viele recht populäre Pakete in
/usr/freeware (früher auch /usr/gnu) installiert. Solange solche
Besonderheiten nicht auch noch Eingang in configure finden sollen,
kommt hier noch der Benutzerfehler (CFLAGS und LDFLAGS nicht angepaßt)
hinzu und configure kann tatsächlich nicht zwischen den Möglichkeiten
entscheiden, schließlich weiß es nicht genug, um diese Entscheidung zu
treffen. "not found" mag ein besserer Text sein, aber das ganze war
auch nur ein Beispiel und die von Dir gemeinte Uneindeutigkeit sollte
wohl keinen intelligenten Menschen in tiefe Verzweiflung stürzen.
Das Beispiel war dann auch noch falsch von mir zitiert (ja ich stecke
gleich einen Korken in die Löcher in meinem Schädel, um das Austreten
von Erinnerungen zu vermeiden), denn check_ssl.m4, der empfohlene Weg,
um openssl einzubinden, gibt dann "Cannot find ssl libraries"
aus. OpenSSL ist demnach sogar ein sehr gutes Beispiel, wie autoconf
eigene Konstruktionen überflüssig macht.
> Es gibt Leute, die (für openssl oder Kerberos 5 zum Beispiel)
> /usr/local/... in configure.in direkt eintragen. Findet configure da
> nichts, bricht der Vorgang mit einem Fehler ab. Auf einem System, zu
Nur hätten die gleichen Leute wohl eine ähnlich fehlerhafte
Konstruktion im selbstgeschriebenen Makefile produziert.
> dem OpenSSL normalerweise gehört (*BSD, Debian etc) wäre das unnötig,
> weil ein simples Testprogram genügt hätte, um die benötigten Dateien
> zu finden. Ggf gibt es --with-ssl[-include-[dir]]-Optionen, die auch
> in der überwiegenden Zahl der Fälle eine Auswirkung haben (aber wenn
> viele Leute unabhängig voneinander Programmteile entwicklen, zB als
> Plugins, garantiert irgendwo nicht), andernfalls muß man das Skript
> ändern. Wo liegt der Vorteil gegenüber einem Hinweis, welche
> systemabhängigen Annahmen im Makefile gemacht werden und wo man ggf an
> sie herankommt?
Vielleicht ja einfach nur darin, daß man den Hinweis nicht erst suchen
muß? Und wenn die Makefiles der z.B. Plugins von anderen geschrieben
werden ist wohl genausowenig garantiert, daß da der gleiche Code zur
Anwendung kommt. Tatsächlich ist dann wohl eher die Wahrscheinlichkeit
größer, daß die Leute die gleichen autoconf-Makros wiederverwerten
(z.B. aus dem genannten Macro Archive?).
[...]
> > nicht in jedem Fall die Aufgabe von autoconf. Exakt dieses Beispiel
> > würde in autoconf durch
> >
> > #!/bin/sh
> > CFLAGS="-I/usr/local/openssl-0.9.7/include" \
> > LDFLAGS="-L/usr/local/openssl-0.9.7/lib" /path/to/configure
> >
> > realisiert. Da kann ich jetzt nicht genau erkennen, in welcher Weise
> > beides differiert.
>
> ZB darin, daß ich ein funktionierendes binary bekomme (Nutzung von
> libtool sollte strafrechtlich verfolgt werden ...).
Jetzt aber mal langsam. libtool dient dem _Erzeugen_ von dynamisch
gelinkten Libs, nicht dem linken dagegen. Könntest Du das vielleicht
etwas konkretisieren?
Thomas Jahns
Nun immerhin sind die nötigen Anpassungen dokumentiert, nicht
sonderlich schwer vorzunehmen und einsichtig, wenn man bedenkt, daß
autoconf einige Zeit keinen Maintainer hatte und währendessen Dinge
die zu autoconf gehören in automake untergebracht wurden. Außerdem
wird einiges der alten Syntax auch weiterhin supported, führt
allerdings zu einer Warnung.
Die eigentlichen Klopper kommen eher dadurch zustande, daß ältere
autoconf-Versionen nicht ganz so strikt bei Dingen wie z.B. dem
Quoting aufgepaßt haben und deshalb falscher Code scheinbar richtige
Ergebnisse hervorbrachte.
Thomas Jahns
> portablen autoconf-Skripten ist eh nicht einfacher, wie man
> an den vielen total kaputten Exemplaren erkennen kann.
Nur ist gerade der Punkt bei autoconf, daß das triviale Nivieau von
oben gar nicht mehr erreicht werden muss, wenn nämlich die Erstellung
eigener autoconf-Makros unterbleiben kann und andererseits die Menge
an erstelltem Code auch in schwierigeren Fällen geringer ist.
> Dinge werden dann portabel, wenn der Programmierer hinreichend
> Erfahrung hat. Dann kann er auch prima portable Shell-Skripte
ACK, nur besteht ein Unterschied zwischen Können und Müssen.
> schreiben. Sonst hilft die portable autoconf-Grundfunktionalität
> auch nichts,
Eben doch, denn die Zahl der Konstruktionen, die der Nutzer von
autoconf einsetzt, ist geringer.
> weil das Projekt selbst sowieso nicht portabel ist.
Sorry fürs auseinanderreißen, aber diesen Halbsatz müßtest Du schon
erläutern:
Ist das erzeugte configure-Skript nicht portabel, weil autoconf per se
keine portablen Skripte erzeugt?
Ist das erzeugte configure-Skript nicht portabel, weil der Nutzer von
autoconf meist nicht-portablen sh-Code produziert?
Sind die autotools selbst nicht hinreichend portabel?
> > Für die angesprochenen einfachen Projekte kann autoconf
> > einem das meist ganz ersparen.
>
> Wofür es dann nur ungefähr das hundertfache an Laufzeit und
> Skriptumfang benötigt. Ich bin schwer beeindruckt von dieser
> Ersparnis.
Da die Laufzeit im Verhältnis sowohl zur aufgewandten Zeit des
Schreibens des Skripts als der Laufzeit des endgültig erzeugten
Programms vernachlässigbar klein ist, halte ich das trotzdem für einen
Gewinn. Offensichtlich werden unsere Standpunkte hier nicht vereinbar
sein, da wir unterschiedliche Gewichtungen vornehmen.
[sind configure-Meldungen zu irreführend? (Nein. Doch. Nein)]
> Du hast das nicht verstanden. Das Problem besteht dann, wenn
> ein configure-Skript zu Unrecht feststellt, daß etwas nicht
> funktioniert. Die meisten dieser Checks sind total überflüssig.
Überflüssig, sobald alles wie gewünscht funktioniert. Der Unterschied
ist eben, daß das configure-Skript dies feststellt, während so manches
selbst erstelltes System dann erstmal munter draufloslegt. Ich gebe
allerdings zu, daß durch m4-Kontrollkonstrukte die mehrfache
Einbindung eines Checks hätte vermieden werden sollen, warum das nicht
ähnlich wie bei mehrfacher Header-Einbindung in C gelöst wurde, weiß
ich nicht.
Was das zu Unrecht angeht, so bestreite ich nicht, daß das
configure-Skript fehlerhaft sein kann, jedoch bin ich der Ansicht, daß
die standardmäßig enthaltenen Checks schon recht gut
funktionieren. Und das war ja auch einer meiner ursprünglichen Punkte:
sie funktionieren im Zweifelsfalle besser, als das was ich mir selbst
überlege, weil sie bereits von sehr viel mehr Personen inspiziert
wurden, als ich zur Kontrolle meiner eigenen Konstruktionen bekommen
werde.
> Man kann die Software bauen und sehen, ob es funktioniert. Und
> wenn es dann nicht funktioniert, kann man sich darum kümmern.
> So checkt erst autoconf, ob es funktioniert, was keine Aussage
> darüber sein muß, ob es bei den eigentlichen Quellen funktioniert
> oder nicht funktioniert. Speziell nicht, wenn der Check von
> Deppen des Typs «Oh weh, Shell ist mir zu kompliziert, ich nehme
> autoconf» fabriziert wurde. Der einzige Effekt dieser Methode ist
> der, daß ich noch an einer weiteren Stelle Code zum Laufen bringen
> muß. Ich bin auch von diesem Vorzug von autoconf schwer beeindruckt.
Nur wissen wir wohl beide, ob ein einmaliger Funktioncheck seitens des
Nutzers alle (nur durch den Build-Prozess entstandenen) Fehler
aufzeigt, oder? Denn durch Verwendung von autoconf sollen ja nicht nur
Fehler vermieden werden, die den build-Prozess fehlschlagen lassen,
sondern auch solche, in denen formal alles in Ordnung, die verwendete
Implementierung aber trotzdem fehlerhaft.
> >> > 2. einfacheres Handling von Systemen, die sich gegen die Portierung
> >> > von Software wehren (nicht vorhandene Libraryfunktionen etc.)
> >> autoconf hilft Dir da nicht wirklich weiter. Die Funktionen
> >> darfst Du alle selber schreiben, autoconf führt nur ein paar
> >> Checks durch. Checks von der Art, wie Du sie oben gerade gesehen
> >> hast, offensichtlich ohne sie zu verstehen. Libraryfunktionen
> >> sind wirklich trivial zu checken, mit oder ohne autoconf.
> > Ich meinte auch sowohl autoconf als auch automake, denn beide sind ein
> > geprüftes Gespann für conditional compilation, um fehlerhafte oder
> > fehlende Funktionen im BS zu ersetzen.
>
> Quatsch. Die gesamte Leistung von autobloat in diesem Bereich besteht
> darin, ein Define bereitzustellen. Genau das hat der Code aus meinem
> vorletzten Posting auch getan.
Nur finde ich den Einsazt von z.B. AC_REPLACE_FUNCS doch sehr viel
einfacher und prägnanter (und es stellt im Zusammenwirken mit automake
auch etwas mehr als einen reinen define bereit).
> > Und wenn man sich ein wenig umsieht, findet man durchaus einige
> > fertige Lösungen, schon das eher magere "Autoconf Macro Archive"
> > enthält viele brauchbare Ansätze.
>
> ROTFL
>
> Lies: Und selbst, wenn man sich lange umgesehen hat, um Deine
> Position zu halten, findet man nur das «Autoconf Macro Archive»,
> das nicht mal für Trivialitäten wie strcasecmp() mehr als einen
> Ansatz bereithält.
Nein, man muss sich gar nicht lange umschauen. In auf ausreichend
viele Systeme portierten Projekten z.B. GNU tar (okay, der Quellcode
von GNU tar selbst ist eklig, aber das ist hier nicht relevant) finden
sich meist wahre Goldgruben. Und fast jeder hat da bestimmt ein paar
geeignete Kandidaten bereits auf der Platte. Das "Autoconf Macro
Archive" war nur das prominenteste Beispiel und der Ort an dem man mit
dem Suchen anfangen sollte, ich meinte nicht, daß man dort auch
aufhören muß, denn daß dort alle brauchbaren Ansätze zu finden sind,
habe ich auch nicht behauptet.
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> > Es gibt Leute, die (für openssl oder Kerberos 5 zum Beispiel)
> > /usr/local/... in configure.in direkt eintragen. Findet configure da
> > nichts, bricht der Vorgang mit einem Fehler ab. Auf einem System, zu
>
> Nur hätten die gleichen Leute wohl eine ähnlich fehlerhafte
> Konstruktion im selbstgeschriebenen Makefile produziert.
Falls ich irgendwo Bibliotheken installiere, dann sorge ich auch
dafür, daß die üblichen Entwicklungstools die finden (sonst wäre das
etwas zweckfrei). Brauche ich unterschiedliche Versionen derselben
Bibliothek gleichzeitig, braucht configure gar nicht erst zu raten
anfangen, welche davon tatsächlich benutzt werden soll.
> > > realisiert. Da kann ich jetzt nicht genau erkennen, in welcher Weise
> > > beides differiert.
> >
> > ZB darin, daß ich ein funktionierendes binary bekomme (Nutzung von
> > libtool sollte strafrechtlich verfolgt werden ...).
>
> Jetzt aber mal langsam. libtool dient dem _Erzeugen_ von dynamisch
> gelinkten Libs, nicht dem linken dagegen. Könntest Du das vielleicht
> etwas konkretisieren?
Auf dem System (NetBSD-1.5.3) sind zwei SSL-Versionen, eine
integrierte und ein Snapshot, der ausschließlich für ein bestimmtes
Programm verwendet werden soll (eigentlich für plug-ins dieses
Programmes). Diese müssen mit dem richtigen Pfad gelinkt werden und
mit LDFLAGS geht das nicht, denn es ist irrelevant, ob der Linker die
irgendwann mal gefunden hat, wenn das plugin das hinterher nicht kann,
weil es nicht weiß, wo es suchen soll.
Gunnar Ritter
> Und Du paßt auch immer schön artig auf, daß die Pattern so einfach
> bleiben, und paßt dann bei Bedarf punktgenau an? Ich habe
> zugegebenermaßen keine Ahnung, wie kompliziert die Sache z.B. bei
> Japanisch wird.
Richtig. Du hast keine Ahnung. Du weißt offensichtlich überhaupt
nicht, um welche Art von Abfrage es hier überhaupt geht. Warum
hältst Du nicht einfach mal die Fresse?
Gunnar
Gunnar Ritter
> Nur ist gerade der Punkt bei autoconf, daß das triviale Nivieau von
> oben gar nicht mehr erreicht werden muss, wenn nämlich die Erstellung
> eigener autoconf-Makros unterbleiben kann und andererseits die Menge
> an erstelltem Code auch in schwierigeren Fällen geringer ist.
Du verstehst das ja immer noch nicht! _Menge_ an Code ist in
weiten Grenzen irrelevant. Wartungsaufwand ist entscheidend.
Und der bemißt sich nicht am «wird schon nichts schiefgehen».
Der orientiert sich an «ich weiß bis ins letzte Detail, was
das macht, weil ich es selbst programmiert habe» vs. «ich
muß mich jetzt erst mal durch Tonnen von m4- mit Shell-Code
anderer Leute durchwühlen, um überhaupt den Ansatzpunkt zu
finden».
>> Wofür es dann nur ungefähr das hundertfache an Laufzeit und
>> Skriptumfang benötigt. Ich bin schwer beeindruckt von dieser
>> Ersparnis.
> Da die Laufzeit im Verhältnis sowohl zur aufgewandten Zeit des
> Schreibens des Skripts als der Laufzeit des endgültig erzeugten
> Programms vernachlässigbar klein ist,
Ist sie nicht. Du bist halt ein Loser, der entweder keine Ahnung
von Shell-Skripten hat oder die Skripte nicht oft benutzt. Anders
kann man Deine Aussagen hier nicht mehr interpretieren. Ich habe
keine Lust mehr, meine Zeit mit Dir zu verschwenden. Verschwende
Du Deine Zeit halt weiter mit autobloat, aber nicht auch noch die
anderer Leute mit Deinem Gefasel.
Gunnar
Gunnar Ritter
> unter SuSE Linux ermittelt
Ich hab's geahnt. Natürlich. Ich hätte es _wissen_ sollen.
Gunnar
Uwe Ohse
>Japanisch wird. Wenn aber irgendwann die Entscheidung, wie vorsichtig
>man sein will, ansteht, kann ich mir gute Gründe für einen eher
>konservativen Standpunkt vorstellen.
"konservativ" ist wirklich das allerletzte Wort, daß mir für die
Verwendungen von regulären Ausdrücken in einer Ja/Nein-Abfrage
eingefallen wäre.
Aber Du könntest "Ahnung" erhalten, würdest Du mal fileutils*/po/*.po
studieren. Die kompliziertest Internationalisierung von "^[yY]" ist
"^[yYaAáÁ]". Und das könnte man mit dem sowieso vorhandenen GNU fnmatch
durchaus eleganter lösen.
>Denn der Sinn ist eben, nur für ein API zu programmieren. Ich weiß
>zugegebenermaßen nicht, wo regexec/regcomp fehlen/fehlerhaft sind,
>aber daß die fileutils einen test enthalten, ausreichend "gute"
>Implementierungen zu identifizieren, ist für mich ein Hinweis, daß es
>wohl auch schlechte gibt.
Die Tatsache, daß irgendwer auf der Welt _glaubt_, daß irgendwo eine
schlechte Implemtierung von irgendetwas existiert, ist ein echt
bescheidener Grund, selbst diese Annahme zu machen.
Gruß, Uwe
Uwe Ohse
>Nun immerhin sind die nötigen Anpassungen dokumentiert, nicht
Hahaha. Guter Witz.
Die Versionsabhängigkeiten von automake, autoconf und libtool untereinander
sind eben nicht dokumentiert - weil sie wirklich keinem der Entwickler
überhaupt noch bewußt sind.
Und wären die Anpassungen dokumentiert, was ich nicht so ganz glaube, ändert
überhaupt nichts daran, daß sie nötig sind.
aclocal.m4: 99: `AM_PROG_INSTALL' is obsolete; use `AC_PROG_INSTALL'
Wo, in welcher Dokumentation, steht, ob das Eine das andere Makro
vollständig ersetzt?
>Die eigentlichen Klopper kommen eher dadurch zustande, daß ältere
>autoconf-Versionen nicht ganz so strikt bei Dingen wie z.B. dem
>Quoting aufgepaßt haben und deshalb falscher Code scheinbar richtige
>Ergebnisse hervorbrachte.
Quark. Das Problem ist vielmehr, daß an autoconf herumgepfuscht wurde,
bis es irgendwann mal aus Gründen der internen Komplexität strikte
Quotingnotwendigkeiten bekam.
>"Computers are good at following instructions,
> but not at reading your mind."
beherzige das.
Gruß, Uwe
Uwe Ohse
>Insgesamt sind wohl trotzdem 1200k von 8.3M (mit du auf i386-reiserfs
>unter SuSE Linux ermittelt) des fileutils-Pakets nicht nahe genug an
>den verlangten 70% (die i18n-Dateien zählen wohl nicht zum autotools
>"Bloat"). Und das, obwohl ein so vielfach verwendetes Paket wie die GNU
Stimmt, die i18n-Sachen sind nicht autotools bloat, die sind i18n-Bloat.
>fileutils sicherlich auf alles portiert worden ist, was nicht
>rechtzeitig auf den Bäumen war, demnach also ein eher atypisches
>Beispiel, wenn es auch das mit den autotools erreichbare sicherlich
>sehr gut demonstriert.
Man kann durchaus auch mit dem Auto zum Nachbarn 20 Meter weiter weg
fahren.
Soll heißen: Daß etwas mit GNU autoconf geht, heißt nicht, daß es anders
nicht eleganter ginge.
>Der Sinn des Cache liegt aber auch nun darin, Situationen wie den gcc
>zu unterstützen, wo zur Kompilation mehrere sub-configure
>ablaufen. Wenn configure geändert wird, so ist es wohl offensichtlich,
>daß der cache der Vorgängerversion gelöscht werden sollte.
Schade, daß die Autoren das nicht gesehen haben. Das sollte gefälligst
automatisch laufen.
>Im Falle autotools sind die Übergänge von einer Version zur nächsten
>allerdings so gestaltet, daß sie nur wenige Anpassungen erfordern.
WAS?
Unter welchem Stein lebst Du? Mit unschöner Regelmäßigkeit kann man
seine Makros an neue Versionen von Autoconf anpassen, und ein Versuch,
eine autoconf nutzende Anwendung von 1.x nach 2.5x zu portieren, artet
in echte Arbeit aus.
Autoconf ist wirklich _das_ Musterbeispiel an völlig fehlender
Rückwärtskompatibilität.
>Daß Gnome und KDE ein Problem bezüglich des Skalierens mit der Zahl
>der Entwickler haben, ist ein Aspekt, der sich durchaus nicht nur in
>den Makefile.am äußert, sondern in den Quellen insgesamt. Wie jemand
>anderes bereits anmerkte, ist es durchaus nicht immer nötig, den Bug im
>Makefile zu suchen, wenn man ihn auch gut in Makefile.am finden kann,
>das nicht nur leichter als das produzierte Makefile sondern auch
>leichter als ein handgeschriebenes Makefile zu lesen sein sollte.
wie oft muß noch erwähnt werden, daß autoconf/automake ein Versionsproblem
haben, und daß man eben nicht, ohne die letzten 10 verschiedenen Versionen
von ihnen (+ libtool, gelegentlich) auf der Platte zu haben, irgendwelche
..am/.ac-Dateien in Makefile/configure übersetzen kann?
Vielleicht kommt das doch mal an: Im Allgemeinen kann man _nicht_
der Input von autoconf/make/libtool durch eine neuere oder ältere
Version dieser Tools übersetzen. Man braucht sehr wahrscheinlich
exakt die Versionen, die der Entwickler damals verwendet hat.
Was gar nicht _so_ fürchterlich schlimm wäre, wenn nicht mehr als die
Hälfte dieser Inkompatibilitäten überflüssig gewesen wären.
>attraktiver. Zumindest mir erscheint das plausibel.
die erste Gruppe sind die Leute, deren Rechner man auch für ein paar
Jahre abschalten könnte, ohne daß das jemandem auffallen würde.
>Daß jemand, der wie Du so grotesk einseitige Positionen vertritt,
>Widerspruch erntet ist wohl nur natürlich und verständlich.
"einseitig" bist Du auch.
Allerdings auch völlig ahnungslos.
>Wenn Dir ein Weg einfällt, vorherzusagen, bei welchem Paket dem
>Einsteiger zuerst das GNU build-system begegnet, bin ich gerne bereit,
>die Datei aus allen anderen Paketen zu eliminieren. Obwohl ich nicht
>meine, daß die 8k (3 nach Komprimierung) ein gigantischer Gewinn
>wären.
ich hab' diese 3K einige 100 mal in den letzten 9 Jahren gesaugt.
Daneben ist mein Plattenplatz wertvoll. Daneben ist diese Datei
alleine wertlos, verweist auf configure --help, und in vielen,
wenn nicht der überwiegenden Mehrheit, der GNU Pakete werden die
Optionen von configure nicht beschrieben. Daneben muß man, um
GNU-Dokumentation zu lesen, sowieso info installieren, und da könnte
man diesen Krempel gleich mit installieren.
Get a clue. autoconf war ein netter Ansatz, ist aber vom Hilfsmittel
zur Philosophie geworden.
Gruß, Uwe
Gunnar Ritter
> "konservativ" ist wirklich das allerletzte Wort, daß mir für die
> Verwendungen von regulären Ausdrücken in einer Ja/Nein-Abfrage
> eingefallen wäre.
Naja, der eigentliche Grund, warum sie das machen, ist wohl der,
daß irgendeinem Papierproduzenten bei der OpenGroup vor vielen
Jahren mal eingefallen ist, daß nl_langinfo(YESEXPR) besonders
bürokratiegeeignet ist, wenn es eine ERE zurückliefert. Wenn
sie bei den GNU fileutils jetzt diesen Wert abfragen würden,
könnte man ihre Vorgehensweise immerhin noch nachvollziehen.
Tun sie aber gar nicht. Ihre Abfrage ist komplett mit ihren
eigenen Message-Files implementiert, und deshalb ist es
unverzeihlich, daß sie da so rumbloaten.
Gunnar
Gunnar Ritter
>>Und dann bekommen wir hier von den autobloat-Junkies erzählt, daß
>>man damit so toll «fehlerhafte oder fehlende Funktionen» ersetzen
>>könne. Ich bin begeistert.
> klar. Auf welchen Systemen, denen reg* fehlt, bekommt man ein MB
> große configure-Scripte durchgenudelt?
SunOS 4 z. B. (im Prinzip, ausprobiert habe ich das nicht).
> -rwxr-xr-x 1 uwe users 1035595 Jul 20 16:00 \
> fileutils-4.1.11/configure
Das ist für sich genommen nicht so furchtbar schlimm, weil die Shell
ja immer nur einen kleinen Teil des Skriptes parst und ausführt (bis
zu einer Stelle, an der sie interaktiv prompten würde) und dann mit
dem nächsten geschlossenen Syntaxabschnitt genauso weitermacht. Es
hängt von der Struktur des Skriptes und nicht allein von der Größe
ab, wieviel Speicher die Shell dafür braucht.
Ich hätte auch kein Problem damit, wenn sie das wirklich bräuchten,
weil sie ernsthaft auf ihre RE-Funktionalität angewiesen wären. Nur
sind sie das hier eben nicht.
Gunnar
Ramon Leon Fournier
> Du verstehst das ja immer noch nicht! _Menge_ an Code ist in
> weiten Grenzen irrelevant. Wartungsaufwand ist entscheidend.
> Ist sie nicht. Du bist halt ein Loser, der entweder keine Ahnung
> von Shell-Skripten hat oder die Skripte nicht oft benutzt. Anders
Das muß ausgerechnet jemand schreiben, der offenbar schon mit
der Wartung der eigenen Signatur überfordert ist:
> --
> http://omnibus.ruf.uni-freiburg.de/~gritter/usenet.html
404 Document not found
Vielleicht solltest du zur Übung mal ein Skript schreiben, das *das*
überprüft, anstatt hier *andere* als Loser zu beschimpfen.
Ramón
--
Horum omnium fortissimi sunt Costarricenses
Gunnar Ritter
> Naja, der eigentliche Grund, warum sie das machen, ist wohl der,
> daß irgendeinem Papierproduzenten bei der OpenGroup vor vielen
> Jahren mal eingefallen ist, daß nl_langinfo(YESEXPR) besonders
> bürokratiegeeignet ist, wenn es eine ERE zurückliefert.
Mit dem Resultat, daß dann in den Locale-Files der glibc Pattern
auftauchen, die offensichtlich von Leuten gemacht wurden, die
nicht wissen, wie eine ERE funktioniert. Zwei schöne Beispiele
(glibc 2.2.5):
· oc_FR, «Occitan Language Locale for France», «[oOsS].*». Wenn
man da «non» eingibt, kommt «ja» raus:
$ >t
$ LC_ALL=oc_FR /bin/rm -i t
/bin/rm: remove `t'? non
$ ls t
t: No such file or directory
$
Das «^» fehlt noch bei einer ganzen Reihe weiterer Locales.
· mr_IN, «Marathi language locale for India», «^(Yes|[yY])». Mit
Vermerk «This is the POSIX Locale definition for the LC_MESSAGES
category generated by IBM Basic CountryPack Transformer. These
are generated based on XML base Locale difintion file for IBM
Class for Unicode».
Begeisternd, nicht?
Gunnar
Stefan Reuther
Gunnar Ritter <g...@bigfoot.de> wrote:
[fileutils enthält dicke eigene regexp-Implementation]
> Ich hätte auch kein Problem damit, wenn sie das wirklich bräuchten,
> weil sie ernsthaft auf ihre RE-Funktionalität angewiesen wären. Nur
> sind sie das hier eben nicht.
Per default matchen die vielleicht nur auf "^[yY]" und "^[nN]".
Aber das muß ja nicht so bleiben.
| yesexpr
| The operand consists of an extended regular expression (see
| Extended Regular Expressions) that describes the acceptable
| affirmative response to a question expecting an affirmative
| or negative response.
| noexpr
| The operand consists of an extended regular expression that
| describes the acceptable negative response to a question
| expecting an affirmative or negative response.
-- Single Unix Specification zum Thema "Locale", "LC_MESSAGES".
Freilich, ich hätte keine Skrupel, beim Fehlen einer Locale-
Infrastruktur auch auf diese Feinheit zu verzichten und das
ganze "ad-hoc" zu lösen. Die fileutils-Leute haben sich aber
anders entschieden.
Stefan
Gunnar Ritter
> Per default matchen die vielleicht nur auf "^[yY]" und "^[nN]".
> Aber das muß ja nicht so bleiben. [...]
> -- Single Unix Specification zum Thema "Locale", "LC_MESSAGES".
Davon gibt es mehrere Versionen, man sollte beim Zitieren angeben,
welche man benutzt hat.
Ansonsten Netiquette, Punkt 5, Absatz 2.
> Freilich, ich hätte keine Skrupel, beim Fehlen einer Locale-
> Infrastruktur auch auf diese Feinheit zu verzichten und das
> ganze "ad-hoc" zu lösen.
Siehst Du.
> Die fileutils-Leute haben sich aber anders entschieden.
Nein, haben sie nicht. Sie verwenden nl_langinfo(YESEXPR) nämlich
gar nicht. Wie ich ebenfalls bereits geschrieben hatte. Nur daß
ihre ad-hoc-Implementation mit EREs halt >8000 Zeilen verbrät.
Ganz toll auch die POSIX-Leute: «yesexpr» und «noexpr» sind POSIX,
aber es gibt innerhalb von plain POSIX gar keine Funktion, mit der
man deren Wert ermitteln könnte. POSIX.2 wie POSIX.1-2001.
Gunnar
Gerd Knorr
> Thomas Jahns wrote:
>
> > Gerd Knorr <kra...@bytesex.org> writes:
>
> >> Schon mal den Fall gehabt daß das installieren nicht so geklappt hat wie
> >> gewollt? Kommt öfter vor wenn man in ein buildroot unter $TMDIR/foo
> >> installieren will um RPMs zu bauen. Schon mal versucht den output von
> >> "make -n install" eines automake buildsystems zu verstehen, um den
> >> Fehler zu finden? Oder gar das Makefile selber?
>
> hmm, der Fehler ist aber oft recht leicht in den Makefile.am zu finden.
... und nach dem fix in Makefile.am automake + autoconf nochmal
durchlaufen zu lassen scheitert oft daran, daß die Versionen zueinander
nicht kompatibel sind und man selber zufälligerweise eine andere hat als
der Entwickler des Paketes :-/
Gerd
--
You can't please everybody. And usually if you _try_ to please
everybody, the end result is one big mess.
-- Linus Torvalds, 2002-04-20
Gerd Knorr
> libtool sollte strafrechtlich verfolgt werden ...).
Genau. Bin immer wieder davon begeistert, daß libtool die binaries beim
"make install" unbedingt neu linken will. Und bei der Gelegenheit
gerne gründlich Mist baut, wenn man in ein buildroot installiert (ja,
mal wieder beim RPMs/debs bauen ...).
Felix von Leitner
> falschen Einsatz von autoconf schneller und leichter ausbügeln kann
> und ich zweitens durch configure sehr viel leichter einen
> Installationsort und andere Parameter des build kontrollieren kann.
Merkst du eigentlich, wenn du dich komplett zum Affen machst, indem du
einen Komparativ benutzt, ohne zu sagen, womit du vergleichst?
Felix von Leitner
Wenn Dummheit stinken würde, bräuchte man in deiner Gegenwart eine
Gasmaske.
> Vielleicht solltest du zur Übung mal ein Skript schreiben, das *das*
> überprüft, anstatt hier *andere* als Loser zu beschimpfen.
Gut, daß du auch ohne Beschimpfung keinen Zweifel an deinen Fähigkeiten
läßt.
Felix von Leitner
> > ZB darin, daß ich ein funktionierendes binary bekomme (Nutzung von
> > libtool sollte strafrechtlich verfolgt werden ...).
> Genau. Bin immer wieder davon begeistert, daß libtool die binaries beim
> "make install" unbedingt neu linken will. Und bei der Gelegenheit
> gerne gründlich Mist baut, wenn man in ein buildroot installiert (ja,
> mal wieder beim RPMs/debs bauen ...).
Ich könnte mich bei libtool ja immer nur wieder über die tausend
überflüssigen Dependencies totlachen. Schon mal beim Bauen von KDE oder
einem typischen GNOME-Programm zugeschaut? Da wird in ein Programm
fünfzig bis hundertmal explizit gegen -lm gelinkt. Und natürlich gegen
-lc (und -lstdc++ bei C++).
Felix
Gunnar Ritter
> Thus spake Gerd Knorr (kra...@bytesex.org):
>> > ZB darin, daß ich ein funktionierendes binary bekomme (Nutzung von
>> > libtool sollte strafrechtlich verfolgt werden ...).
>> Genau. Bin immer wieder davon begeistert, daß libtool die binaries beim
>> "make install" unbedingt neu linken will. Und bei der Gelegenheit
>> gerne gründlich Mist baut, wenn man in ein buildroot installiert (ja,
>> mal wieder beim RPMs/debs bauen ...).
> Ich könnte mich bei libtool ja immer nur wieder über die tausend
> überflüssigen Dependencies totlachen. Schon mal beim Bauen von KDE oder
> einem typischen GNOME-Programm zugeschaut?
Schon mal versucht, mit libtool, GNU libc und Intel C-Compiler eine
dynamische Library zu bauen? Das macht Spaß. Mein letzter Workaround
war, irgendwas wie --target=some-ancient-sysv anzugeben. Überflüssig
zu erwähnen, daß die so immerhin hergestellten dynamischen Libraries
nicht funktioniert haben.
Wie gerne hätte ich in einem Makefile einfach CFLAGS=-KPIC angegeben!
Aber diese Chance bekam ich nicht.
Und wie heißt es im Info-File von libtool so schön? «Libtool is under
constant development, changing to remain up-to-date with modern
operating systems». Nicht, daß im «Alpha Release» vom 7. Januar 2002
(!) irgendwas von Support für diese Umgebung zu erkennen wäre. Und
nein, _ich_ passe diesen Müllhaufen bestimmt nicht daran an.
Gunnar