./aclocal.m4:2181: error: m4_defn: undefined macro:
Karl Wagner
ich verwende hier SuSE Linux 7.3 mit Kdevelop 2.0.1 unter KDE 2.2.1.
Wenn ich ein c++ oder ein QT Projekt kompilieren möchte, tritt
folgender Fehler auf:
-------------------------------------------------------------------
Starting with installation
App [Test12] Type [cpp]
unpacking <template.tar.gz> in </home/karl/test12>...
changing files [cpp]...
Starting with configuration
creating configuration files...
>make -f Makefile.dist
cat acinclude.m4.in libtool.m4.in >acinclude.m4
aclocal
autoheader
make configure...
>LDFLAGS=" " CFLAGS="-O0 -g3 -Wall" CXXFLAGS="-O0 -g3 -Wall"
./configure
> creating user documentation... sgml2html index.sgml
Processing file index.sgml
READY
-----------------------------------------------------------------------
---
./aclocal.m4:2181: error: m4_defn: undefined macro:
_m4_divert_diversion
acfunctions.m4:1108: AM_FUNC_OBSTACK is expanded from...
./aclocal.m4:2181: the top level
autoconf: tracing failed
make: *** [all] Error 1
sh: ./configure: Datei oder Verzeichnis nicht gefunden
-----------------------------------------------------------------------
------
Also scheint mir irgendwie ein M4 Makro zu fehlen oder? Anyway, viel
anfangen, kann ich mir der Fehlermeldung nicht.
Kann mir jemand sagen, wie ich den Fehler beseitigen kann oder mich
sonst auf den richtigen Pfad der Tugend bringen (Lesen kann ich schon
selber, wenn man mir sagt wo :) ),
Gruss,
Karl.
Enrico Scholz
> Hallo,
> ich verwende hier SuSE Linux 7.3 mit Kdevelop 2.0.1 unter KDE 2.2.1.
> Wenn ich ein c++ oder ein QT Projekt kompilieren möchte, tritt
> folgender Fehler auf:
> [...]
> cat acinclude.m4.in libtool.m4.in >acinclude.m4
~~~~~~~~~~~~~
Das sieht so aus, als ob die Kdevelop Entwickler den Sinn von automake &
Co. nicht so ganz verstanden haben. Diese Aktion macht es unmoeglich,
das Projekt mit anderen libtool Versionen zu entwickeln.
> [...]
> ../aclocal.m4:2181: error: m4_defn: undefined macro:
> _m4_divert_diversion
> acfunctions.m4:1108: AM_FUNC_OBSTACK is expanded from...
> ../aclocal.m4:2181: the top level
> [...]
> Also scheint mir irgendwie ein M4 Makro zu fehlen oder?
Ich vermute einen Versionskonflikt zwischen lokalem automake/autoconf
und dem, was Kdevelop erwartet.
> Anyway, viel anfangen, kann ich mir der Fehlermeldung nicht. Kann mir
> jemand sagen, wie ich den Fehler beseitigen kann
Ich wuerde zuerst saemtliche Spuren von libtool.m4.in und anderen
Standard-Makros aus dem acinclude.m4 entfernen. Dann kann es normal
weitergehen:
1. libtoolize --force ## evtl. noch missing entfernen
2. aclocal
3. automake
4. autoconf
5. autoheader
6. ./configure --enable-maintainer-mode ...
7. make
> oder mich sonst auf den richtigen Pfad der Tugend bringen (Lesen kann
> ich schon selber, wenn man mir sagt wo :) ),
info automake
info autoconf
sind ein guter Anfang.
Enrico
Felix von Leitner
> Das sieht so aus, als ob die Kdevelop Entwickler den Sinn von automake &
> Co. nicht so ganz verstanden haben.
Es gibt ja auch keinen.
automake gehört direkt und ohne Umwege in die Tonne.
Felix
Enrico Scholz
> > Das sieht so aus, als ob die Kdevelop Entwickler den Sinn von
> > automake & Co. nicht so ganz verstanden haben.
>
> Es gibt ja auch keinen.
> automake gehört direkt und ohne Umwege in die Tonne.
Ok, es ist zwar in perl geschrieben und bringt keine Vorteile beim
Compilieren von Dokumentation und Handling einiger Skriptsprachen. Es
ist aber der beste Weg, um Standardaufgaben wie Abhaengigkeitenchecks,
Programminstallation und Paketbildung mit einem minimalen Aufwand
durchzufuehren.
Enrico
Felix von Leitner
> Compilieren von Dokumentation und Handling einiger Skriptsprachen. Es
> ist aber der beste Weg, um Standardaufgaben wie Abhaengigkeitenchecks,
> Programminstallation und Paketbildung mit einem minimalen Aufwand
> durchzufuehren.
Abhängigkeitschecks macht bei mir make.
Programminstallation macht bei mir install.
Paketbildung macht bei mir tar.
Felix
Karl Wagner
Gruss,
Karl.
Enrico Scholz
> > [... automake ...]
> > Es ist aber der beste Weg, um Standardaufgaben wie
> > Abhaengigkeitenchecks, Programminstallation und Paketbildung mit
> > einem minimalen Aufwand durchzufuehren.
>
> Abhängigkeitschecks macht bei mir make.
Wie bringst Du make dazu, Abhaengigkeiten zwischen C-Quellen zu
beachten? Werden die statisch eingetragen, oder verfolgst Du einen
(automake-aehnlichen) Ansatz, bei dem sie dynamisch bestimmt werden?
> Programminstallation macht bei mir install.
> Paketbildung macht bei mir tar.
Hier machen das automatisch generierte Makefiles, welche durch wenige
handgeschriebene Zeilen in Makefile.am & configure.ac erzeugt werden.
Selbstgeschriebene Loesungen zur Programminstallation und Paketbildung
sind entweder speziell fuer's jeweilige Projekt zugeschnitten und
verursachen jedesmal neue Arbeit. Oder sie sind generell gehalten und
bilden automake nach. Da automake mehr Nutzer hat, ist es in diesem
Fall aber wahrscheinlich fehlerfreier und maechtiger.
Enrico
Gerd Knorr
> > Abhängigkeitschecks macht bei mir make.
>
> Wie bringst Du make dazu, Abhaengigkeiten zwischen C-Quellen zu
> beachten? Werden die statisch eingetragen, oder verfolgst Du einen
> (automake-aehnlichen) Ansatz, bei dem sie dynamisch bestimmt werden?
gccmakedep
> > Programminstallation macht bei mir install.
> > Paketbildung macht bei mir tar.
>
> Hier machen das automatisch generierte Makefiles, welche durch wenige
> handgeschriebene Zeilen in Makefile.am & configure.ac erzeugt werden.
Und die Lesbarkeit der automatisch generierten Makefiles ist unter aller
Sau, weil dieselben mit allem möglichen Rotz aufgebläht werden. Wenn
dann mal was nicht funkioniert wie es soll bist Du gründlich am fluchen.
Auch immer wieder schön sind Pakete, die unbedingt auf der lokalen
Maschine ein automake durchlaufen lassen wollen und bei der Gelegenheit
gründlich auf die Schnauze fallen, weil maintainer und user
unterschiedliche Versionen von autoconf/automake installiert haben ...
autoconf ist ja genial, aber bleib mir bloß weg mit automake. Ein
handgeschriebenes "make install" sind auch nur ein paar weniger Zeilen.
Gerd
--
Netscape is unable to locate the server localhost:8000.
Please check the server name and try again.
Enrico Scholz
> > Wie bringst Du make dazu, Abhaengigkeiten zwischen C-Quellen zu
> > beachten? Werden die statisch eingetragen, oder verfolgst Du einen
> > (automake-aehnlichen) Ansatz, bei dem sie dynamisch bestimmt werden?
>
> gccmakedep
Toll. Und wie wird das ins Makefile eingebunden, so dass es auf
geaenderte Umstaende (neue/entfernte Dateien, ./configure mit anderen
Optionen) ordnungsgemaess reagiert? Ich bezweifle nicht, dass sowas
moeglich ist; nur wird das von automake schon automatisch gemacht.
> > > Programminstallation macht bei mir install.
> > > Paketbildung macht bei mir tar.
> >
> > Hier machen das automatisch generierte Makefiles, welche durch wenige
> > handgeschriebene Zeilen in Makefile.am & configure.ac erzeugt werden.
>
> Und die Lesbarkeit der automatisch generierten Makefiles ist unter
> aller Sau,
wieso sollte man solche Makefiles lesen wollen? Ein `less /bin/bash'
sagt mir auch nicht viel.
> [...]
> Auch immer wieder schön sind Pakete, die unbedingt auf der lokalen
> Maschine ein automake durchlaufen lassen wollen
Man kann die meisten Tools zur fehlerhaften Arbeit zwingen. Wie man es
korrekt macht, steht in
info automake --> i maintainer-mo <CR>
> und bei der Gelegenheit gründlich auf die Schnauze fallen, weil
> maintainer und user unterschiedliche Versionen von autoconf/automake
> installiert haben ...
Solange man -- anders als im Ursprungsposting geschrieben -- nicht
Standardmakros ins acinclude.m4 einbindet, macht das keine Probleme.
> autoconf ist ja genial, aber bleib mir bloß weg mit automake. Ein
> handgeschriebenes "make install" sind auch nur ein paar weniger Zeilen.
Und wenn das ueber mehrere Unterverzeichnisse geht, schreibt man das in
jedes Verzeichnis. Wenn man noch nuetzliche Targets wie 'make distcheck'
hinzufuegt, hat man stundenlang an etwas gesessen, was von automake zum
Nulltarif mitgeliefert wird.
Enrico
Andreas Ferber
>
> Und die Lesbarkeit der automatisch generierten Makefiles ist unter aller
> Sau, weil dieselben mit allem möglichen Rotz aufgebläht werden. Wenn
> dann mal was nicht funkioniert wie es soll bist Du gründlich am fluchen.
Teilweises ACK. Manchmal macht automake tatsächlich nicht so ganz das
gewünschte, andererseits fand ich die Makefiles nach ein bisschen
Gewöhnung eigentlich recht lesbar.
> Auch immer wieder schön sind Pakete, die unbedingt auf der lokalen
> Maschine ein automake durchlaufen lassen wollen und bei der Gelegenheit
> gründlich auf die Schnauze fallen, weil maintainer und user
> unterschiedliche Versionen von autoconf/automake installiert haben ...
Das passiert aber nur dann, wenn der Autor unbedingt seine Distribution
mit tar selbst erstellen will, anstatt das eigentlich dafür vorgesehene
"make dist" zu benutzen. Letzteres baut dann auch die automatischen
Dependencies fest in die Makefiles, so daß das Ergebnis auch nicht mehr
auf GNU make angewiesen ist.
> autoconf ist ja genial, aber bleib mir bloß weg mit automake. Ein
> handgeschriebenes "make install" sind auch nur ein paar weniger Zeilen.
automake tut aber noch ein /bisschen/ mehr.
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - a...@devcon.net - www.devcon.net
Gerd Knorr
> Gerd Knorr <kra...@bytesex.org> writes:
> > gccmakedep
>
> Toll. Und wie wird das ins Makefile eingebunden, so dass es auf
> geaenderte Umstaende (neue/entfernte Dateien, ./configure mit anderen
> Optionen) ordnungsgemaess reagiert? Ich bezweifle nicht, dass sowas
> moeglich ist; nur wird das von automake schon automatisch gemacht.
Es gibt ein "make depend", etwa so:
depend dep:
gccmakedep -- $(CFLAGS) -- *.c
> > Und die Lesbarkeit der automatisch generierten Makefiles ist unter
> > aller Sau,
>
> wieso sollte man solche Makefiles lesen wollen?
Weil sie mitunter buggy sind?
> > [...]
> > Auch immer wieder schön sind Pakete, die unbedingt auf der lokalen
> > Maschine ein automake durchlaufen lassen wollen
>
> Man kann die meisten Tools zur fehlerhaften Arbeit zwingen. Wie man es
> korrekt macht, steht in
>
> info automake --> i maintainer-mo <CR>
Und? Das ändert nichts an meinem Problem. Wenn's der maintainer nicht
begriffen hat muß ich mich als user trotzdem damit herumärgern, egal ob
das jetzt gescheit dokumentiert ist oder nicht. Der einfachste fix für
dieses Problem ist übrigens "rpm -e automake".
> > autoconf ist ja genial, aber bleib mir bloß weg mit automake. Ein
> > handgeschriebenes "make install" sind auch nur ein paar weniger Zeilen.
>
> Und wenn das ueber mehrere Unterverzeichnisse geht, schreibt man das in
> jedes Verzeichnis. Wenn man noch nuetzliche Targets wie 'make distcheck'
> hinzufuegt, hat man stundenlang an etwas gesessen, was von automake zum
> Nulltarif mitgeliefert wird.
Du schreibst stundenlang Makefiles? Irgendwas machst Du falsch...
Enrico Scholz
> Es gibt ein "make depend", etwa so:
>
> depend dep:
> gccmakedep -- $(CFLAGS) -- *.c
Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien das `make
depend' beim naechsten `make' automatisch durchgefuehrt wird. Ebenso, wenn
ich in foo.c ein neues `#include ...' einfuege. Natuerlich sollten nur die
deps von foo.c und nicht die von bar.c geupdated werden.
Ein manueller Aufruf von `make dep' ist nicht sehr sinnvoll.
> > > Und die Lesbarkeit der automatisch generierten Makefiles ist unter
> > > aller Sau,
> >
> > wieso sollte man solche Makefiles lesen wollen?
>
> Weil sie mitunter buggy sind?
Fuer Standardaufgaben (z.B. die ganzen k* und g* Applikationen)
funktioniert automake fehlerfrei. Evtl. kommt es bei Sachen mit
z.B. komplizierten Libraryabhaengigkeiten zu Problemen. Dort kommt
man ohne Kenntnisse von make auch so nicht weiter. Mit solchen
Kenntnissen kann man dann aber auch die automake-Makefiles lesen.
> > > [...]
> > Man kann die meisten Tools zur fehlerhaften Arbeit zwingen. [...]
>
> Und? Das ändert nichts an meinem Problem. Wenn's der maintainer
> nicht begriffen hat muß ich mich als user trotzdem damit herumärgern,
Stimmt. Wie gesagt, ist das ueberall so.
> [...]
> Du schreibst stundenlang Makefiles?
Nein. Ich verwende automake.
Enrico
Felix von Leitner
> Wie bringst Du make dazu, Abhaengigkeiten zwischen C-Quellen zu
> beachten? Werden die statisch eingetragen, oder verfolgst Du einen
> (automake-aehnlichen) Ansatz, bei dem sie dynamisch bestimmt werden?
$ gcc -MM *.c >> Makefile
> > Programminstallation macht bei mir install.
> > Paketbildung macht bei mir tar.
> Hier machen das automatisch generierte Makefiles, welche durch wenige
> handgeschriebene Zeilen in Makefile.am & configure.ac erzeugt werden.
Ich schreibe meine Makefiles selber. Das hat den Vorteil, daß sie
a) funktionieren
b) nicht auf schrottige Schweine-Software wie automake depended
c) keine obskuren Dependencies auf irgendwelche m4-includes haben
d) kein perl brauchen, um meine Software zu kompilieren
e) wartbar sind
automake macht _nur_ Ärger und die "Quellen", aus denen dieser
Bloat-Müll dann seine Monster-Makefiles generiert, sind gewöhnlich
größer als meine Makefiles.
> Selbstgeschriebene Loesungen zur Programminstallation und Paketbildung
> sind entweder speziell fuer's jeweilige Projekt zugeschnitten und
> verursachen jedesmal neue Arbeit. Oder sie sind generell gehalten und
> bilden automake nach. Da automake mehr Nutzer hat, ist es in diesem
> Fall aber wahrscheinlich fehlerfreier und maechtiger.
Unfug. Du bist ja gefährlich in deiner Naivität!
Felix von Leitner
> autoconf ist ja genial,
Auch darüber kann man geteilter Meinung sein.
autoconf selber ist keine schlechte Idee, aber wenn bei meinen
sämtlichen Projekten configure deutlich größer ist als der Rest des
Projektes kombiniert, dann ist das nicht akzeptabel.
Im Übrigen können die ganzen Windoze-Umsteiger und Visual-Basic-Athleten
autoconf nicht bedienen und erzeugen dann hanebüchene configure.ac,
deren Reparatur am Ende aufwendiger ist, als das ganze Projekt neu zu
schreiben.
Felix
Felix von Leitner
> depend' beim naechsten `make' automatisch durchgefuehrt wird.
Und genau deswegen bist du eine Gefahr für deine Umwelt und hast hiermit
bis auf weiteres Programmierverbot. Künstlich Intelligente
Schrott-Software von Versagern wie dir ist es, die überproportional Zeit
verschwendet, weil der "Experte" Tools einsetzt, die er nicht wirklich
versteht, und seine grandiose Software als erstes nach Einspielen eines
Patches (manchmal auch ohne Patch!) erkennt, daß configure neu gemacht
werden soll, und bei mir irgendwelche anderen Versionen von auto* und
libt00l findet und dabei alles zerschießt.
make AUTOCONF=: AUTOHEADER=: AUTOMAKE=: ACLOCAL=:
ist bei mir zum stehenden Idiom geworden, weil es so viele von deiner
Sorte gibt. KOTZ! Stirb, Luser!
> Fuer Standardaufgaben (z.B. die ganzen k* und g* Applikationen)
> funktioniert automake fehlerfrei.
Das Gegenteil ist der Fall.
Aus dem CVS kann man GNOME genau gar nicht kompilieren, weil diverse
Pakete verschiedene Versionen von automake verlangen, die natürlich
nicht kompatibel sind. ZUM KOTZEN, diese Dreckware!
Und bei KDE hat man aufgegeben und die Substition in Perl
reimplementiert, weil autoconf so unglaublich ineffizient ist.
In typischen kleinen bis mittelgroßen Projekten braucht configure länger
als das make danach. Ich finde das absolut inakzeptabel. Wenn du dich
an dynamischen und undeterministischen Systemen aufgeilen willst, dann
kannst du dich von mir aus gerne mit Java auseinandersetzen. Aber bleib
weg von mir und Produktivsoftware! Marodeur, elender!
> Evtl. kommt es bei Sachen mit z.B. komplizierten
> Libraryabhaengigkeiten zu Problemen. Dort kommt man ohne Kenntnisse
> von make auch so nicht weiter. Mit solchen Kenntnissen kann man dann
> aber auch die automake-Makefiles lesen.
Was für ein unglaublicher Bullshit.
Es gibt bei anständig entworfener Software keine komplizierten
Libraryabhängigkeiten. Du dependest auf "-lpng -lz" und fertig.
Geh weg.
Felix von Leitner
> Teilweises ACK. Manchmal macht automake tatsächlich nicht so ganz das
> gewünschte, andererseits fand ich die Makefiles nach ein bisschen
> Gewöhnung eigentlich recht lesbar.
Dann lies dir mal das Makefile von qmail durch. So als Vergleichswert.
Oder das von libowfat oder der diet libc, wenn du mal sehen willst, was
für Features make so hat, die die automake-Jünger nicht kennen und daher
eine Daseinsberechtigung für automake daherfabulieren.
In der Praxis ist es schlicht so, daß automake ständig Streß macht.
Definiere dir mal einen zentralen autoconf Cache, zum Beispiel.
Oder /usr/share/autoconf vs. /usr/local/share/autoconf vs.
/opt/gnome/share/autoconf vs. /usr/X11R6/share/autoconf
Gut, das kann man mit einer zentralen autoconf Konfigurationsdatei
beheben, aber außer mir selbst ist mir noch niemand begegnet, der das
wußte und umgesetzt hat.
KOTZ!!!!
Oder probiere doch mal, die typische autoconf/automake/libtool
verseuchte Software zu crosscompilen. Als nettes Anschauungsobjekt
empfehle ich glib. Ich habe da vor einem Jahr Patches eingeschickt, die
das behoben hätten. So weit ich weiß sind die bis heute noch nicht
eingebaut worden. Warum? Keiner versteht diesen autoconf/automake Müll
und daher ändert man daran erst etwas, wenn es einem selbst auf die Füße
fällt.
> Das passiert aber nur dann, wenn der Autor unbedingt seine Distribution
> mit tar selbst erstellen will, anstatt das eigentlich dafür vorgesehene
> "make dist" zu benutzen. Letzteres baut dann auch die automatischen
> Dependencies fest in die Makefiles, so daß das Ergebnis auch nicht mehr
> auf GNU make angewiesen ist.
Ich möchte gerne mein Paket mit prefix=/usr kompilieren, aber bei make
install nach /tmp/fefix/usr installiert haben. Kein Problem, sollte man
denken. Typische Anforderung von Distributionsbauern, sollte man
denken. In der Praxis muß man jedes zweite Paket anfassen, weil der
durchschnittliche Softwareentwickler a) noch nie von Cross-Compilern
gehört hat und b) Tools einsetzt, die er bei weitem nicht beherrscht.
> > autoconf ist ja genial, aber bleib mir bloß weg mit automake. Ein
> > handgeschriebenes "make install" sind auch nur ein paar weniger Zeilen.
> automake tut aber noch ein /bisschen/ mehr.
Ja. Streß, Ärger und Wutausbrüche erzeugen. Den Blutdruck senken.
Grandios versagen. So Sachen.
Enrico Scholz
> > Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien
> > das `make depend' beim naechsten `make' automatisch durchgefuehrt
> > wird.
>
> Und genau deswegen bist du eine Gefahr für deine Umwelt und hast
> hiermit bis auf weiteres Programmierverbot. Künstlich Intelligente
> Schrott-Software von Versagern wie dir ist es, die überproportional
> Zeit verschwendet,
Was ist daran Zeitverschwendung, wenn die Software genau das macht, was
ich auch machen wuerde? Neue Dateien bringen neue Abhaengigkeiten mit.
Zeitverschwendung waere es, wenn ich manuell ein `make dep' aufrufen
muesste.
> weil der "Experte" Tools einsetzt, die er nicht wirklich versteht, und
> seine grandiose Software als erstes nach Einspielen eines Patches
> (manchmal auch ohne Patch!) erkennt, daß configure neu gemacht werden
> soll,
Wenn der Patch eine Abhaengigkeit von configure aendert, dann muss
configure neu gemacht werden. Der Fall ohne Patch ist wahrscheinlich
durch ein fehlendes AM_MAINTAINER_MODE hervorgerufen, und Du solltest
einen Bugreport schreiben.
> und bei mir irgendwelche anderen Versionen von auto* und libt00l
> findet und dabei alles zerschießt.
Der libt00l-Fall wird dadurch hervorgerufen, dass unnoetigerweise
Standardmacros (AC_PROG_LIBTOOL) ins acinclude.m4 eingefuegt werden. Bei
auto* ist entweder Aehnliches passiert, oder es laesst sich durch einen
einmaligen Aufruf von `aclocal' beheben.
> [...]
> In typischen kleinen bis mittelgroßen Projekten braucht configure
> länger als das make danach. Ich finde das absolut inakzeptabel.
Welche Methode verwendest Du, um Pfade, Compileroptionen und Libraries
zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
> Wenn du dich an dynamischen und undeterministischen Systemen aufgeilen
> willst,
Das Compilieren von Paketen unter verschiedenen Plattformen ist dynamisch
und undeterministisch.
> > Evtl. kommt es bei Sachen mit z.B. komplizierten
> > Libraryabhaengigkeiten zu Problemen. Dort kommt man ohne Kenntnisse
> > von make auch so nicht weiter. Mit solchen Kenntnissen kann man dann
> > aber auch die automake-Makefiles lesen.
>
> Was für ein unglaublicher Bullshit.
> Es gibt bei anständig entworfener Software keine komplizierten
> Libraryabhängigkeiten. Du dependest auf "-lpng -lz" und fertig.
Ich meinte Probleme in Paketen, die Libraries selbst mitbringen und sich
dagegen linken.
Enrico
Gerd Knorr
> Gerd Knorr <kra...@bytesex.org> writes:
>
> > Es gibt ein "make depend", etwa so:
> >
> > depend dep:
> > gccmakedep -- $(CFLAGS) -- *.c
>
> Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien das `make
> depend' beim naechsten `make' automatisch durchgefuehrt wird.
Bahnhof? Bei neuen source-files mußt Du die doch erst mal im
Makefile.am eintragen, oder? Und danach ist ja eh' erst mal ein
"./configure && make depend" fällig ...
> Ebenso, wenn
> ich in foo.c ein neues `#include ...' einfuege. Natuerlich sollten nur die
> deps von foo.c und nicht die von bar.c geupdated werden.
>
> Ein manueller Aufruf von `make dep' ist nicht sehr sinnvoll.
Warum nicht? Also bei mir ändern sich die Dependences nicht am
laufenden Band. Und bei jedem mtime update eines source files die
dependences zu checken halte ich für 'ne Verschwendung von Rechenzeit.
> z.B. komplizierten Libraryabhaengigkeiten zu Problemen. Dort kommt
> man ohne Kenntnisse von make auch so nicht weiter. Mit solchen
> Kenntnissen kann man dann aber auch die automake-Makefiles lesen.
Klar kann es lesen, aber es macht definitiv keinen Spaß sich da
durchzukämpfen.
> > [...]
> > Du schreibst stundenlang Makefiles?
>
> Nein. Ich verwende automake.
Ich nicht. Und ich hab meine Makefiles trotzdem schnell fertig.
Andreas Ferber
>
> Dann lies dir mal das Makefile von qmail durch. So als Vergleichswert.
Done. Und? Das Makefile ist einfacher zu verstehen als ein von automake
generiertes, zugegeben. Aber um welchen Preis?
- kein Gebrauch von impliziten Rules, für jedes poplige Objectfile wird
das Compile-Kommando jeweils erneut aufgeführt
- keine automatische Dependency-Generierung
- die eigentliche Arbeit wird in externe Shellskripte verlagert, so daß
ich durch ansehen des Makefiles alleine nicht feststellen kann, was da
eigentlich jetzt wirklich passiert ("./compile foo.c", schön. CC?
CFLAGS?... Alleine an der Generierung des compile-Skriptes sind neben
dem Makefile 5 Sourcefiles und 4 in Zwischenschritten angelegte
Skripte beteiligt, der Output der temporären Skripte wird jeweils in
den weiteren Schritten verwendet)
- die Konfiguration des Buildprozesses erfolgt über zig kleine separate
Files, "standardisierte" Environmentvariablen wie CC und CFLAGS werden
völlig ignoriert.
Dadurch wird das Makefile zwar einfacher, aber wartbarer IMO nicht.
> Oder das von libowfat oder der diet libc, wenn du mal sehen willst, was
> für Features make so hat, die die automake-Jünger nicht kennen und daher
> eine Daseinsberechtigung für automake daherfabulieren.
Ich kenne (und benutze) die Features von make (speziell GNU make) auch,
trotzdem lehne ich automake nicht grundsätzlich ab.
> In der Praxis ist es schlicht so, daß automake ständig Streß macht.
> Definiere dir mal einen zentralen autoconf Cache, zum Beispiel.
Done, seit ein paar Jahren. Inklusive cronjob, der den Cache einmal im
Monat leert und mit den Ergebnissen der Standard-autoconf-Makros
vorbefüllt.
Einziges konkret aufgetretenes Problem damit bisher der Build der
Debian-mysql-Pakete, da dieser an einer Stelle erwartet, daß
config.cache im Builddirectory angelegt wird.
> Gut, das kann man mit einer zentralen autoconf Konfigurationsdatei
> beheben, aber außer mir selbst ist mir noch niemand begegnet, der das
> wußte und umgesetzt hat.
Dann kannst du mich mit auf deine Liste setzen.
> Oder probiere doch mal, die typische autoconf/automake/libtool
> verseuchte Software zu crosscompilen. Als nettes Anschauungsobjekt
> empfehle ich glib.
Mag sein, meine Erfahrungen mit crosscompilieren beschränken sich bisher
auf ein Minimum.
> Ich habe da vor einem Jahr Patches eingeschickt, die
> das behoben hätten. So weit ich weiß sind die bis heute noch nicht
> eingebaut worden.
Und daran soll automake Schuld sein? Meines Wissens muss das Integrieren
von Patches immer noch manuell geschehen.
> Warum? Keiner versteht diesen autoconf/automake Müll
> und daher ändert man daran erst etwas, wenn es einem selbst auf die Füße
> fällt.
Wenn das Problem bei automake selbst liegt, dann bist du bei den
glib-Maintainern auch an der falcshen Adresse.
> Ich möchte gerne mein Paket mit prefix=/usr kompilieren, aber bei make
> install nach /tmp/fefix/usr installiert haben. Kein Problem, sollte man
> denken.
Genau. Geht bei _jedem_ autoconf/automake-basierten Projekt, das nicht
in den "install-*-local"-Hooks Unfug macht, mit "./configure
--prefix=/usr && make && make DESTDIR=/tmp/fefix install". Wenn
install-*-local DESTDIR ignoriert, liegt das nicht an automake.
> Typische Anforderung von Distributionsbauern, sollte man
> denken.
Dann schau dir mal die GNU Makefile Conventions an, insbesondere den
Punkt "Install Command Categories". Da automake diese Konventionen
vollständig berücksichtigt, bietet dir ein Projekt mit sauber
implementiertem automake-Support sogar die Möglichkeit, ein
Distributionspaket vollautomatisch erstellen zu lassen.
> In der Praxis muß man jedes zweite Paket anfassen, weil der
> durchschnittliche Softwareentwickler a) noch nie von Cross-Compilern
> gehört hat und b) Tools einsetzt, die er bei weitem nicht beherrscht.
Ack. Und inwiefern war nochmal autoconf oder automake daran schuld?
Andreas Ferber
> Makefile.am eintragen, oder? Und danach ist ja eh' erst mal ein
> "./configure && make depend" fällig ...
Nein. Das Makefile sorgt selbst dafür, daß es auf dem neuesten Stand
ist.
> Warum nicht? Also bei mir ändern sich die Dependences nicht am
> laufenden Band. Und bei jedem mtime update eines source files die
> dependences zu checken halte ich für 'ne Verschwendung von Rechenzeit.
Deswegen werden die Dependencies von automake-Makefiles beim normalen
Kompilieren nebenbei mitgeneriert (siehe [1] dazu, wie das
funktioniert). Dafür ist gcc nötig, für nicht-gccs werden daher beim
"make dist" die Dependencies fest ins Makefile gebacken.
Andreas
[1] http://www.paulandlesley.org/gmake/autodep.html
Enrico Scholz
> > Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien
> > das `make depend' beim naechsten `make' automatisch durchgefuehrt
> > wird.
>
> Bahnhof? Bei neuen source-files mußt Du die doch erst mal im Makefile.am
> eintragen, oder?
ja; so wie bei allen Makefile-Loesungen.
> Und danach ist ja eh' erst mal ein "./configure && make depend" fällig
Nein. Ein `make' genuegt und Makefile{,.in} wird automatisch geupdated.
> [...]
> > Ein manueller Aufruf von `make dep' ist nicht sehr sinnvoll.
>
> Warum nicht?
Man kann es vergessen, was unnoetige Fehler provoziert; die Eingabe
bereitet Aufwand und es existieren Loesungen, die es automatisch
erledigen.
> Also bei mir ändern sich die Dependences nicht am laufenden Band. Und
> bei jedem mtime update eines source files die dependences zu checken
> halte ich für 'ne Verschwendung von Rechenzeit.
Der dep-check ist wahrscheinlich schneller als das Eingeben von `make
dep' und dem Ueberlegen, ob man es wirklich braucht.
Enrico
Felix von Leitner
> das Compile-Kommando jeweils erneut aufgeführt
Ja, und?
> - keine automatische Dependency-Generierung
Woher weißt du das? Für mich sieht das ausgesprochen regelmäßig (will
sagen: generiert) aus und ich habe auch mal ein paar Perl-Scripte
geschrieben, die mit solchen Makefiles arbeiten können.
> - die eigentliche Arbeit wird in externe Shellskripte verlagert, so daß
> ich durch ansehen des Makefiles alleine nicht feststellen kann, was da
> eigentlich jetzt wirklich passiert ("./compile foo.c", schön. CC?
> CFLAGS?... Alleine an der Generierung des compile-Skriptes sind neben
> dem Makefile 5 Sourcefiles und 4 in Zwischenschritten angelegte
> Skripte beteiligt, der Output der temporären Skripte wird jeweils in
> den weiteren Schritten verwendet)
$ ls conf-*
$ more INSTALL
RTFM ;)
> - die Konfiguration des Buildprozesses erfolgt über zig kleine separate
> Files, "standardisierte" Environmentvariablen wie CC und CFLAGS werden
> völlig ignoriert.
Sie sind ja auch nicht Standard, sondern Wichsvorlage der GNU Generation
und der BSD-Hippies. Ich empfinde es als Vorteil, denn sein Buildprozeß
ist nicht von der Locale, irgendwelchen Dot-Files oder dem Environment
abhängig, sondern funktioniert einfach deterministisch und
nachvollziehbar.
> Dadurch wird das Makefile zwar einfacher, aber wartbarer IMO nicht.
Oh, _deutlich_ wartbarer, weil ohne großes Wissen über make verständlich
und wartbar. Keinerlei impliziter Kram, alles ist explizit
ausformuliert.
> Ich kenne (und benutze) die Features von make (speziell GNU make) auch,
> trotzdem lehne ich automake nicht grundsätzlich ab.
Selbst schuld.
> > Gut, das kann man mit einer zentralen autoconf Konfigurationsdatei
> > beheben, aber außer mir selbst ist mir noch niemand begegnet, der das
> > wußte und umgesetzt hat.
> Dann kannst du mich mit auf deine Liste setzen.
OK. Zwei von ein paar Hundert. Kein toller Schnitt.
> > Ich habe da vor einem Jahr Patches eingeschickt, die
> > das behoben hätten. So weit ich weiß sind die bis heute noch nicht
> > eingebaut worden.
> Und daran soll automake Schuld sein? Meines Wissens muss das Integrieren
> von Patches immer noch manuell geschehen.
DAS IST JA DER PUNKT!
Die Leute benutzen Tools, die sie nicht beherrschen, und trauen sich
dann nicht, Fehler zu beheben, außer sie fallen ihnen persönlich massiv
auf den Fuß.
> > Ich möchte gerne mein Paket mit prefix=/usr kompilieren, aber bei make
> > install nach /tmp/fefix/usr installiert haben. Kein Problem, sollte man
> > denken.
> Genau. Geht bei _jedem_ autoconf/automake-basierten Projekt, das nicht
> in den "install-*-local"-Hooks Unfug macht, mit "./configure
> --prefix=/usr && make && make DESTDIR=/tmp/fefix install". Wenn
> install-*-local DESTDIR ignoriert, liegt das nicht an automake.
Aber doch! Das ist ja der Punkt: die einzigen Vorteile, die ich mir
bei automake denken kann, sind ja gerade die Vereinheitlichung.
Trotzdem können Idioten das anders machen (und tun es dann natürlich
auch).
> > In der Praxis muß man jedes zweite Paket anfassen, weil der
> > durchschnittliche Softwareentwickler a) noch nie von Cross-Compilern
> > gehört hat und b) Tools einsetzt, die er bei weitem nicht beherrscht.
> Ack. Und inwiefern war nochmal autoconf oder automake daran schuld?
Sie erfüllen eine minimale Aufgabe, diese erfüllen sie bemerkenswert
schlecht bis gar nicht, und sie sind dabei viel zu komplex, um vom
durchschnittlichen Programmierer verstanden werden zu können. Dadurch
entstehen unwartbare monströse Bloat-Monster, mit denen nicht einmal der
Maintainer selber klar kommt.
Tools sind gut, wenn man nichts weglassen kann, nicht wenn man nichts
mehr dazu tun kann.
Das ist die zentrale Erkenntnis, die man von djb lernen kann (und
sollte). qmail braucht kein autoconf, automake oder libtool, um
die internen und externen Library-Dependencies zu managen.
Ich muß bei jedem zweiten Projekt in config.log herumgraben, weil wieder
irgendwas nicht richtig detected wurde. Daß ich überhaupt herausfinden
mußte, wie man autoconf Scripts debuggt sagt schon alles über die
"Segen" von autoconf und co aus.
Felix
Felix von Leitner
> ich auch machen wuerde?
Wenn du genau das auch tun würdest, dann bist du ein sehr schlechter
Programmierer und gehörst irgendwo eingesperrt, wo du deine Software
nicht auf die Welt loslassen kannst.
> Neue Dateien bringen neue Abhaengigkeiten mit.
Lies dir mal die make-Dokumentation durch!
> Welche Methode verwendest Du, um Pfade, Compileroptionen und Libraries
> zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
$ make prefix=/usr CFLAGS="-Os -pipe"
Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
ohne externe Hilfe, welche Libraries benötigt werden!
> Das Compilieren von Paketen unter verschiedenen Plattformen ist dynamisch
> und undeterministisch.
$ gcc -s -O -pipe -o main *.c
Felix
Herbert Martin Dietze
> Woher weißt du das? Für mich sieht das ausgesprochen regelmäßig (will
> sagen: generiert) aus und ich habe auch mal ein paar Perl-Scripte
> geschrieben, die mit solchen Makefiles arbeiten können.
Hehe, Perl benutzen, aber TCL nicht moegen :-)
SCNR,
Herbert
--
Albert Camus wrote that the only serious question is whether to kill yourself
or not. Tom Robbins wrote that the only serious question is whether time has
a beginning and an end. Camus clearly got up on the wrong side of bed, and
Robbins must have forgotten to set the alarm. -- Tom Robbins
-=-=- -=-=-=-=-
Dipl.Ing. Martin "Herbert" Dietze -=-=- The University of Buckingham -=-=-
Andreas Ferber
>> - kein Gebrauch von impliziten Rules, für jedes poplige Objectfile wird
>> das Compile-Kommando jeweils erneut aufgeführt
> Ja, und?
Redundanz. Und um diese dann nicht zu gross werden zu lassen, wird
unnötigerweise die eigentliche Arbeit in externe Skripte verlagert.
>> - keine automatische Dependency-Generierung
> Woher weißt du das? Für mich sieht das ausgesprochen regelmäßig (will
> sagen: generiert) aus und ich habe auch mal ein paar Perl-Scripte
> geschrieben, die mit solchen Makefiles arbeiten können.
Dann ist die qmail-Distribution unvollständig.
>> - die Konfiguration des Buildprozesses erfolgt über zig kleine separate
>> Files, "standardisierte" Environmentvariablen wie CC und CFLAGS werden
>> völlig ignoriert.
s/"//g
> Sie sind ja auch nicht Standard, sondern Wichsvorlage der GNU Generation
> und der BSD-Hippies.
Sie sind Standard, spätestens seit SUSv2 (andere Standards habe ich hier
momentan nicht vorliegen).
> Ich empfinde es als Vorteil, denn sein Buildprozeß
> ist nicht von der Locale, irgendwelchen Dot-Files oder dem Environment
> abhängig, sondern funktioniert einfach deterministisch und
> nachvollziehbar.
Den Buildprozess von der locale abhängig zu machen ist in der Tat ein
wenig merkwürdig (davor ist aber auch djb nicht gefeit, es wird sich
sicher eine locale konstruieren lassen, bei der schon das Lesen des
Makefiles fehlschlägt). Aber was spricht dagegen, durch Setzen von CC
den normalerweise zu verwendenden C-Compiler festzulegen? djb mag noch
so intelligent sein, ich kenne mein System trotzdem besser als er.
> Die Leute benutzen Tools, die sie nicht beherrschen, und trauen sich
> dann nicht, Fehler zu beheben, außer sie fallen ihnen persönlich massiv
> auf den Fuß.
Glaubst du, diese Leute kämen mit einem selbstgeschriebenen Makefile
besser klar?
> Aber doch! Das ist ja der Punkt: die einzigen Vorteile, die ich mir
> bei automake denken kann, sind ja gerade die Vereinheitlichung.
Ja. Die Vereinheitlichung für den Enduser.
> Trotzdem können Idioten das anders machen (und tun es dann natürlich
> auch).
Dem Entwickler das Denken und Doku Lesen abnehmen kann nicht automakes
Aufgabe sein, und sollte es auch nie sein.
> Sie erfüllen eine minimale Aufgabe, diese erfüllen sie bemerkenswert
> schlecht bis gar nicht, und sie sind dabei viel zu komplex, um vom
> durchschnittlichen Programmierer verstanden werden zu können. Dadurch
> entstehen unwartbare monströse Bloat-Monster, mit denen nicht einmal der
> Maintainer selber klar kommt.
Ich sehe da vor allem ein inhärentes Problem von make. Der
Dependency-Graph wird im Makefile nur rein formal beschrieben, eine
wirklich anschauliche Darstellung ist aufgrund der Makefile-Syntax
nicht einmal andeutungsweise durch entsprechende Formatierung möglich.
Das dann noch gepaart mit den nicht gerade intuitiven Regeln für die
Makroauswertung ergibt eine Mischung, die offenbar vor allem grössere
Makefiles für viele Leute schwer verständlich macht.
> Tools sind gut, wenn man nichts weglassen kann, nicht wenn man nichts
> mehr dazu tun kann.
Hmm, wer redete in einem Vorposting denn davon, welche tollen Features
make alles hat? Die kann man alle weglassen, und kann dann trotzdem noch
funktionierende Makefiles bauen. Aber will man das?
> Das ist die zentrale Erkenntnis, die man von djb lernen kann (und
> sollte). qmail braucht kein autoconf, automake oder libtool, um
> die internen und externen Library-Dependencies zu managen.
Kunststück, wenn man keine Libraries ausser der libc verwendet. Das ist
aber nicht immer praktikabel.
> Ich muß bei jedem zweiten Projekt in config.log herumgraben, weil wieder
> irgendwas nicht richtig detected wurde.
Bisher liess sich das bei mir meistens mit einem "aclocal; autoconf;
automake" beheben.
Aber ein Argument gegen autoconf habe ich auch ;-)
autoconf doktert im Grunde immer nur an Symptomen herum, denen, die
durch die Vielgestaltigkeit von Unix entstanden sind. In einer idealen
Welt wäre autoconf überflüssig. Leider ist es aber ein paar Jahrzehnte
zu spät, die Ursachen noch zu beseitigen, so daß einem nichts anderes
übrigbleibt, als die Symptome so gut wie möglich zu umschiffen. Daß das
niemals perfekt funktionieren kann, ist selbstverständlich, und
diejenigen, die sich weiter ab vom "Mainstream" begeben als andere,
müssen leider den Preis dafür zahlen.
Florian Weimer
> Thus spake Enrico Scholz (enrico...@informatik.tu-chemnitz.de):
> > Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien das `make
>> depend' beim naechsten `make' automatisch durchgefuehrt wird.
>
> Und genau deswegen bist du eine Gefahr für deine Umwelt und hast hiermit
> bis auf weiteres Programmierverbot.
Enricos Erwartung ist durchaus angemessen. Allerdings läßt sich das
mit Build-Tools aus den Siebzigern eben nicht zuverlässig realisieren.
In manchen Kreisen scheint man grundlegende Probleme mit einem
Werkzeug, das wie make auf eher niedriger Abstraktionsebene
angesiedelt ist und bereits dort erhebliche Defizite aufweist, dadurch
lösen zu wollen, indem man ein weiteres Werkzeug, das auf einer
höheren Ebene operiert, darüberlegt, in der Hoffnung, daß es die
Fehler der unteren Ebene verdecken möge.
Das hat uns automake beschert, autoconf (ein Werkzeug, dessen positive
Wirkung kaum geleugnet werden kann, auch wenn heutzutage kaum jemand
mehr weiß, was man mit den ganzen Testergebnissen anfangen soll),
imake, C++, POSIX.5 usw.
Enrico Scholz
> > > > Und wie ist das drumrum? Ich erwarte z.B., dass bei neuen Dateien
> > > > das `make depend' beim naechsten `make' automatisch durchgefuehrt
> > > > wird.
> > [...]
> > Was ist daran Zeitverschwendung, wenn die Software genau das macht, was
> > ich auch machen wuerde?
>
> Wenn du genau das auch tun würdest, dann bist du ein sehr schlechter
> Programmierer
Wenn eine neue Datei[1] zum Projekt hinzugefuegt wird, wuerde ich noetige
Abhaengigkeiten bestimmen wollen. Was ist daran falsch?
> [...]
> > Welche Methode verwendest Du, um Pfade, Compileroptionen und Libraries
> > zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
> [...]
> Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> ohne externe Hilfe, welche Libraries benötigt werden!
??? Erst lehnst Du "Künstlich Intelligente Schrott-Software" ab, und
jetzt forderst Du, dass Projekte automatisch die noetigen Libraries
bestimmen?
> > Das Compilieren von Paketen unter verschiedenen Plattformen ist
> > dynamisch und undeterministisch.
>
> $ gcc -s -O -pipe -o main *.c
--------
#include <stdio.h>
#include <wchar.h>
int main() { wprintf(L""); }
--------
[SuSE Linux 6.4]
$ gcc -s -O -pipe -o main *.c
/tmp/ccFv9jmd.o: In function `main':
/tmp/ccFv9jmd.o(.text+0xf): undefined reference to `wprintf'
$
[RH 7.1]
$ gcc -s -O -pipe -o main *.c
$
Was ist jetzt an `gcc -s -O -pipe -o main *.c' deterministisch?
Enrico
Footnotes:
[1] ich spreche von C oder C++ Quelldateien
Felix von Leitner
> >> das Compile-Kommando jeweils erneut aufgeführt
> > Ja, und?
> Redundanz. Und um diese dann nicht zu gross werden zu lassen, wird
> unnötigerweise die eigentliche Arbeit in externe Skripte verlagert.
Das Makefile soll make instruieren, welche Sachen er in welcher
Reihenfolge zu bearbeiten hat. Es macht durchaus Sinn, das "wie"
auszugliedern. Ich finde das bei qmail sehr gelungen.
> > Woher weißt du das? Für mich sieht das ausgesprochen regelmäßig (will
> > sagen: generiert) aus und ich habe auch mal ein paar Perl-Scripte
> > geschrieben, die mit solchen Makefiles arbeiten können.
> Dann ist die qmail-Distribution unvollständig.
Wieso das denn?
Es kann (und sollte) dir egal sein, wie Bernstein zu seinem Makefile
kommt. Es funktioniert und ist les- und wartbar. Wäre ja noch schöner,
wenn jetzt jeder seine IDE bei seinen Paketen mitliefert!
[$CC und $CFLAGS]
> > Sie sind ja auch nicht Standard, sondern Wichsvorlage der GNU Generation
> > und der BSD-Hippies.
> Sie sind Standard, spätestens seit SUSv2 (andere Standards habe ich hier
> momentan nicht vorliegen).
Standard ist, daß diese Flags von make benutzt werden.
Standard ist nicht, wie man welches davon wo zu setzen hat und welche
Auswirkungen das am Ende hat. Es gibt viele Projekte, bei denen man
CFLAGS nicht einfach von außen setzen darf, weil das Teil intern
irgendwo noch -Ihier -Ldort anfügt und das halt nicht tut, wenn man das
übernagelt hat.
Kurz: als Knob für einen Build-Prozeß ist beides unbrauchbar.
> Aber was spricht dagegen, durch Setzen von CC den normalerweise zu
> verwendenden C-Compiler festzulegen?
Nichts. Kannst du ja auch tun. Aber halt nicht immer und überall, und
damit ist es nicht verläßlich und damit praktisch wertlos. qmail
verzichtet daher absichtlich darauf, weil immer wieder Leute CC und
CFLAGS in ihrem .profile setzen und sich dann über merkwürdige Effekte
wundern.
> > Die Leute benutzen Tools, die sie nicht beherrschen, und trauen sich
> > dann nicht, Fehler zu beheben, außer sie fallen ihnen persönlich massiv
> > auf den Fuß.
> Glaubst du, diese Leute kämen mit einem selbstgeschriebenen Makefile
> besser klar?
Nein, aber dann könnte man das leichter warten als im Moment.
Es passiert mir immer wieder, daß ich irgendwo etwas editiere, weil
irgendeines dieser lästigen "ich bin schlauer als du" Projekte mal
wieder Mist gemacht hat, und make findet dann irgendwelche zirkulären
Dependencies und überschreibt meine Änderung sofort wieder.
Das ist massivst zum Kotzen und diese Programmierer gehören erschossen.
> Ich sehe da vor allem ein inhärentes Problem von make. Der
> Dependency-Graph wird im Makefile nur rein formal beschrieben, eine
> wirklich anschauliche Darstellung ist aufgrund der Makefile-Syntax
> nicht einmal andeutungsweise durch entsprechende Formatierung möglich.
Warum auch?
Wer da einen nichttrivialen Graphen in seinem Projekt erzeugt, hat etwas
falsch gemacht.
> Das dann noch gepaart mit den nicht gerade intuitiven Regeln für die
> Makroauswertung ergibt eine Mischung, die offenbar vor allem grössere
> Makefiles für viele Leute schwer verständlich macht.
Wozu braucht man eigentlich größere Makefiles?
Das Makefile der diet libc ist knapp 10k groß, davon ist über die Hälfte
statische Dependencies. Ein normaler Build erzeugt knapp 700 Dateien
pro Architektur, doppelt so viele, wenn man die dynamische Version mit
baut. Klein ist das Projekt also nicht.
> > Tools sind gut, wenn man nichts weglassen kann, nicht wenn man nichts
> > mehr dazu tun kann.
> Hmm, wer redete in einem Vorposting denn davon, welche tollen Features
> make alles hat? Die kann man alle weglassen, und kann dann trotzdem noch
> funktionierende Makefiles bauen. Aber will man das?
Ja, make könnte gehörig geschrumpft werden.
Und die Zusatz-Features hätte man über externe Kommandos und Filter
prima lösen können. Aber wenn wir make schon haben, gehen die Features
nicht weg, wenn wir sie nicht nutzen.
> > Das ist die zentrale Erkenntnis, die man von djb lernen kann (und
> > sollte). qmail braucht kein autoconf, automake oder libtool, um
> > die internen und externen Library-Dependencies zu managen.
> Kunststück, wenn man keine Libraries ausser der libc verwendet. Das ist
> aber nicht immer praktikabel.
Äh, -lsocket -lnsl? -lresolv?
Felix
Felix von Leitner
> > > ich auch machen wuerde?
> > Wenn du genau das auch tun würdest, dann bist du ein sehr schlechter
> > Programmierer
> Wenn eine neue Datei[1] zum Projekt hinzugefuegt wird, wuerde ich noetige
> Abhaengigkeiten bestimmen wollen. Was ist daran falsch?
automake bestimmt keine Dependencies.
Ich dachte, du benutzt es, und kennst dich also damit aus?
> > > Welche Methode verwendest Du, um Pfade, Compileroptionen und Libraries
> > > zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
> > Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> > ohne externe Hilfe, welche Libraries benötigt werden!
> ??? Erst lehnst Du "Künstlich Intelligente Schrott-Software" ab, und
> jetzt forderst Du, dass Projekte automatisch die noetigen Libraries
> bestimmen?
Automatisch? Unfug. Du benutzt sie, du trägst sie ein.
Das nimmt dir weder automake noch autoconf noch libtool ab.
Sagtest du nicht, daß du obige Programme benutzt und dich also zumindest
rudimentär damit auskennst?
> > > Das Compilieren von Paketen unter verschiedenen Plattformen ist
> > > dynamisch und undeterministisch.
> > $ gcc -s -O -pipe -o main *.c
> --------
> #include <stdio.h>
> #include <wchar.h>
> int main() { wprintf(L""); }
> --------
> [SuSE Linux 6.4]
> $ gcc -s -O -pipe -o main *.c
> /tmp/ccFv9jmd.o: In function `main':
> /tmp/ccFv9jmd.o(.text+0xf): undefined reference to `wprintf'
> $
> [RH 7.1]
> $ gcc -s -O -pipe -o main *.c
> $
> Was ist jetzt an `gcc -s -O -pipe -o main *.c' deterministisch?
Alles! Der Compiler tut exakt das gleiche.
In dem einen Fall ist benötigte Funktionalität nicht vorhanden, also
funktioniert deine Software nicht. Im anderen Fall doch. Ob du
vorher detectest, ob die Funktionalität da ist oder nicht spielt keine
Rolle. Wenn die Funktionalität nicht essentiell für dein Programm ist,
gibt es keine Entschuldigung dafür, daß du sie überhaupt benutzt hast.
Felix
Enrico Scholz
> [...]
> automake bestimmt keine Dependencies.
Es erstellt aber Makefile-Regeln, die das machen.
> > > Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> > > ohne externe Hilfe, welche Libraries benötigt werden!
> > ??? Erst lehnst Du "Künstlich Intelligente Schrott-Software" ab, und
> > jetzt forderst Du, dass Projekte automatisch die noetigen Libraries
> > bestimmen?
>
> Automatisch? Unfug. Du benutzt sie, du trägst sie ein. Das nimmt
> dir weder automake noch autoconf noch libtool ab.
Es kann aber ohne Nutzerinteraktion bestimmt werden, ob -lpthread benoetigt
wird, ob `-I/usr/kerberos/include' oder `-I/usr/local/kerberos/include'
korrekt ist u.ae.
> > --------
> > #include <stdio.h>
> > #include <wchar.h>
>
> > int main() { wprintf(L""); }
> > --------
>
> [...] Ob du vorher detectest, ob die Funktionalität da ist oder nicht
> spielt keine Rolle.
Doch. Im letzteren Falle koennte Ersatzfunktionalitaet programmiert
werden, die bei Bedarf hinzugelinkt wird. Zumindest kann dem Nutzer
nach ein paar Sekunden ./configure mitgeteilt werden, dass das Paket
nicht compilieren wird, ohne dafuer X Stunden Rechenzeit zu investieren.
Enrico
Felix von Leitner
> Es erstellt aber Makefile-Regeln, die das machen.
Äh, ja und? Cut und Paste.
Mir ist es weitgehend egal, womit du als Entwickler das Makefile deines
Projektes erstellst, solange es
a) korrekt
b) lesbar
c) wartbar
d) minimal
ist. Bei automake-Projekten ist sind b, c und d inhärent nicht gegeben
und a wird auch häufig verletzt.
> > Automatisch? Unfug. Du benutzt sie, du trägst sie ein. Das nimmt
> > dir weder automake noch autoconf noch libtool ab.
> Es kann aber ohne Nutzerinteraktion bestimmt werden, ob -lpthread benoetigt
> wird, ob `-I/usr/kerberos/include' oder `-I/usr/local/kerberos/include'
> korrekt ist u.ae.
Klar kann es das. Was hat das mit automake zu tun?
> > [...] Ob du vorher detectest, ob die Funktionalität da ist oder nicht
> > spielt keine Rolle.
> Doch. Im letzteren Falle koennte Ersatzfunktionalitaet programmiert
> werden, die bei Bedarf hinzugelinkt wird.
Wenn du Ersatzfunktionalität hast, wieso benutzt du sie dann nicht
immer?
> Zumindest kann dem Nutzer nach ein paar Sekunden ./configure
> mitgeteilt werden, dass das Paket nicht compilieren wird, ohne dafuer
> X Stunden Rechenzeit zu investieren.
Meine Meinung von dir sinkt stündlich weiter.
Leute, die configure abbrechen lassen, gehören sofort vor die Wand
gestellt und erschossen. Ich habe in meiner gesamten Laufbahn EIN
EINZIGES configure entdeckt, das mit dem Abbruch Recht hatte. Alle
anderen waren kaputte Checks und irgendwelche automake-Seiteneffekte und
anderer Hirnschaden aus dem Hause GNU, um den ich händisch herumarbeiten
mußte. Um dann gewöhnlich festzustellen, daß make erstmal meine
Änderungen rückgängig zu machen versucht.
Felix
Enrico Scholz
> a) korrekt
> b) lesbar
> c) wartbar
> d) minimal
>
> ist. Bei automake-Projekten ist sind b, c und d inhärent nicht
> gegeben und a wird auch häufig verletzt.
Warum willst Du unbedingt Makefile lesen? Auf Makefile.am koennen
diese 4 Punkte zutreffen.
> > > [...] Ob du vorher detectest, ob die Funktionalität da ist oder nicht
> > > spielt keine Rolle.
> > Doch. Im letzteren Falle koennte Ersatzfunktionalitaet
> > programmiert werden, die bei Bedarf hinzugelinkt wird.
>
> Wenn du Ersatzfunktionalität hast, wieso benutzt du sie dann
> nicht immer?
Weil vielleicht eine native-Implementierung existieren koennte,
die performanter ist? (z.B. LAPACK Bibliothek vs. handgeschriebene
Routinen)
> > Zumindest kann dem Nutzer nach ein paar Sekunden ./configure
> > mitgeteilt werden, dass das Paket nicht compilieren wird,
> > ohne dafuer X Stunden Rechenzeit zu investieren.
>
> Meine Meinung von dir sinkt stündlich weiter.
> Leute, die configure abbrechen lassen, gehören sofort vor die Wand
> gestellt und erschossen.
Wie wuerdest Du z.B. SSH kompilieren, wenn ./configure die SSL
Header nicht gefunden hat? Oder wenn Library Version X noetig
ist, aber nur X-1 installiert ist?
> Ich habe in meiner gesamten Laufbahn EIN EINZIGES configure
> entdeckt, das mit dem Abbruch Recht hatte. Alle anderen waren
> kaputte Checks und irgendwelche automake-Seiteneffekte und
> anderer Hirnschaden aus dem Hause GNU, um den ich händisch
> herumarbeiten mußte.
Stimmt. Aber dieser "Hirnschaden" existiert, und man muss damit so
gut wie moeglich zurechtkommen. autoconf ist ein entsprechender
Versuch, der in den vielen Faellen funktioniert.
Enrico
Gerd Knorr
> > zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
>
> $ make prefix=/usr CFLAGS="-Os -pipe"
>
> Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> ohne externe Hilfe, welche Libraries benötigt werden!
Nana, das ist schon netter, klassischer Anwendungsfall für autoconf
(nicht automake): Feature foo unter Zuhilfe von library bar als compile
time option implementieren. Je nachdem ob libbar auf dem jeweiligen
System installiert ist oder nicht wird foo eben unterstützt oder nicht.
*Das* bekommt man mit make alleine schwerlich hin.
Gerd Knorr
> * Gerd Knorr <kra...@bytesex.org> schrieb:
> >
> > Bahnhof? Bei neuen source-files mußt Du die doch erst mal im
> > Makefile.am eintragen, oder? Und danach ist ja eh' erst mal ein
> > "./configure && make depend" fällig ...
>
> Nein. Das Makefile sorgt selbst dafür, daß es auf dem neuesten Stand
> ist.
Aha. Und woher weiß das Makefile welche source files es zu welchen
binaries zusammencompiliert und -gelinkt werden sollen? Black magic?
Felix von Leitner
> > Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> > ohne externe Hilfe, welche Libraries benötigt werden!
> Nana, das ist schon netter, klassischer Anwendungsfall für autoconf
> (nicht automake): Feature foo unter Zuhilfe von library bar als compile
> time option implementieren. Je nachdem ob libbar auf dem jeweiligen
> System installiert ist oder nicht wird foo eben unterstützt oder nicht.
> *Das* bekommt man mit make alleine schwerlich hin.
Stimmt.
Andererseits machen Compile Time Optionen Software unübersichtlich.
Ich habe in meiner Software den Fall bisher nicht gehabt. Wenn ich ihn
hätte, würde ich die Optionen über Plugins oder kleine externe Programme
isolieren, deren Compile dann halt fehlschlägt, wenn die Funktionalität
nicht da ist.
Felix
Enrico Scholz
> Aha. Und woher weiß das Makefile welche source files es zu welchen
> binaries zusammencompiliert und -gelinkt werden sollen?
z.B.:
---- configure.ac[1] -------
| AC_INIT(NAME,0.0.1, email)
| AM_INIT_AUTOMAKE($PACKAGE_NAME, $PACKAGE_VERSION)
| AC_CONFIG_SRCDIR([foo.cc])
| AM_CONFIG_HEADER([config.h])
| AM_MAINTAINER_MODE
|
| AC_CONFIG_FILES([Makefile])
| AC_OUTPUT
--
---- Makefile.am -------
| htmldir = ${pkglibdir}/html
| html_PROGRAMS = foo-prog
| foo_prog_SOURCES = foo.cc # bar.cc
| include_HEADERS = foo.hh
| noinst_HEADERS = bar.hh
--
$ aclocal; autoheader; automake --foreign -a; autoconf
$ ./configure --enable-maintainer-mode
ermoeglicht:
- `make' -> Generieren von foo-prog; Bestimmen + Beachten der
Abhaengigkeiten von foo.cc & bar.cc; beim Hinzufuegen von `bar.cc'
zu den `foo_prog_SOURCES' und anschliessendem `make' wird das
Makefile neu generiert
- `make install' -> `make' + Installation von
* foo-prog nach ${DESTDIR}${htmldir} (dafuer steht das `html' in
html_PROGRAMS; bin_PROGRAMS ist aber ueblicher);
* foo.hh nach ${DESTDIR}${includedir}
* bar.hh wird nicht installiert
- `make dist' -> Generieren eines tar-Paketes NAME-0.0.1.tar.gz
(inkl. {foo,bar}.{cc,hh}), so dass der Nutzer das uebliche
`./configure && make' ausfuehren kann. Dabei werden nur die
Dateien gepackt, die explizit aufgefuehrt wurden (also kein
.nfsXXXX, core, *.o oder aehnliches).
- `make distcheck' -> Ueberpruefung, ob `make dist' keine Dateien
vergessen hat + Check, ob `make uninstall' vollstaendig ist.
> Black magic?
Nein. IMO gut dokumentiert.
Enrico
Footnotes:
[1] groesstenteils aus Vorschlaegen von `autoscan' entstanden
Florian Weimer
> Aha. Und woher weiß das Makefile welche source files es zu welchen
> binaries zusammencompiliert und -gelinkt werden sollen? Black magic?
Das läßt sich z.B. der Verzeichnisstruktur eines Projektes entnehmen.
Damit nicht irgendwie herumliegende Quelldateien versehentlich
mitkompiliert werden, kann man eine Liste der zum Projekt gehörigen
Dateien vom CMS beziehen, welches die Information zwangsläufig
irgendwo bereithält.
Felix von Leitner
> > Aha. Und woher weiك das Makefile welche source files es zu welchen
> > binaries zusammencompiliert und -gelinkt werden sollen? Black magic?
Auf Deutsch: der Programmierer sagt es make.
Na so ein Zufall. Genau, was wir vorher behauptet hatten.
Felix
Florian Weimer
> Thus spake Florian Weimer (f...@deneb.enyo.de):
> > > Aha. Und woher weiß das Makefile welche source files es zu welchen
>> > binaries zusammencompiliert und -gelinkt werden sollen? Black magic?
>> Das läßt sich z.B. der Verzeichnisstruktur eines Projektes entnehmen.
>
> Auf Deutsch: der Programmierer sagt es make.
Sofern er make verwendet, ja.
> Na so ein Zufall. Genau, was wir vorher behauptet hatten.
Kann man, auch wenn man irgendein make und nicht GNU make verwendet,
in diesem Fall in der Praxis ohne einen zusätzlichen Eintrag im
Makefile auskommen?
Nicht daß das ein Killerkriterium wäre -- fehlende Abhängigkeiten, die
zu fehlenden Objektdateien führen, fallen meistens sofort auf, somit
ist das Gegensteuern weniger ein Problem als bei anderen vorhandenen,
aber nicht aufgeführten Abhängigkeiten. (Ich brauchte vor einiger
Zeit ein bißchen, bis ich feststellte, daß das OpenSSH-Makefile keine
Abhängigkeiten von Header-Dateien enthält. So etwas ergibt natürlich
teilweise ein recht interessantes Laufzeitverhalten.)
Felix von Leitner
> Kann man, auch wenn man irgendein make und nicht GNU make verwendet,
> in diesem Fall in der Praxis ohne einen zusätzlichen Eintrag im
> Makefile auskommen?
Klar. patsubst, wildcard und Konsorten sind kein GNU-Feature sondern
POSIX, soweit ich weiß.
> Nicht daß das ein Killerkriterium wäre -- fehlende Abhängigkeiten, die
> zu fehlenden Objektdateien führen, fallen meistens sofort auf, somit
> ist das Gegensteuern weniger ein Problem als bei anderen vorhandenen,
> aber nicht aufgeführten Abhängigkeiten. (Ich brauchte vor einiger Zeit
> ein bißchen, bis ich feststellte, daß das OpenSSH-Makefile keine
> Abhängigkeiten von Header-Dateien enthält.
Solange die Header-Dateien statisch sind und keine Patches ausgeliefert
werden ist das ja auch in Ordnung. Ansonsten muß man darauf achten, daß
die Header-Dateien nicht binär-inkompatibel geändert werden.
Felix
Florian Weimer
> Klar. patsubst, wildcard und Konsorten sind kein GNU-Feature sondern
> POSIX, soweit ich weiß.
SUSv2 kennt nur $(string1[:subst1=[subst2]]), was anderes gibt es da
nicht. Gut, man könnte make rekursiv aufrufen und vorher mit der
Shell die Variablen passend setzen...
>> (Ich brauchte vor einiger Zeit ein bißchen, bis ich feststellte,
>> daß das OpenSSH-Makefile keine Abhängigkeiten von Header-Dateien
>> enthält.
>
> Solange die Header-Dateien statisch sind und keine Patches ausgeliefert
> werden ist das ja auch in Ordnung.
Findest Du? *Das* gehört doch nun wirklich in die Kategorie
"dysfunktionales Makefile".
> Ansonsten muß man darauf achten, daß die Header-Dateien nicht
> binär-inkompatibel geändert werden.
Oder grundsätzlich mit "make clean && make" übersetzen (was ich dann
gemacht habe). :-/
Felix von Leitner
> > werden ist das ja auch in Ordnung.
> Findest Du? *Das* gehört doch nun wirklich in die Kategorie
> "dysfunktionales Makefile".
Wieso? Finde ich nicht.
Bei der diet libc z.B. habe ich so gut wie keine Dependencies auf
Header-Files drin. Denn die Strukturen darin werden mit Sicherheit
nicht geändert werden, da kommen höchstens Prototypen oder neue
Strukturen hinzu. D.h. wenn es vorher kompilierte, kompiliert es auch
nachher.
> > Ansonsten muß man darauf achten, daß die Header-Dateien nicht
> > binär-inkompatibel geändert werden.
> Oder grundsätzlich mit "make clean && make" übersetzen (was ich dann
> gemacht habe). :-/
Der Enduser wird gewöhnlich an dem Projekt nicht herumdoktorn.
Daher ist es um Größenordnungen wichtiger, daß er es sauber bauen kann,
wenn er nicht herumgepfuscht hat, als dafür zu sorgen, daß er sich nicht
in den Fuß schießen kann. Erfahrungsgemäß funktioniert letzteres eh
nicht.
Dependencies sind trotzdem wichtig, solange ihr Fehlen einem parallelen
Build im Wege steht.
Felix
Florian Weimer
> Thus spake Florian Weimer (f...@deneb.enyo.de):
> > > Solange die Header-Dateien statisch sind und keine Patches ausgeliefert
>> > werden ist das ja auch in Ordnung.
>> Findest Du? *Das* gehört doch nun wirklich in die Kategorie
>> "dysfunktionales Makefile".
>
> Wieso? Finde ich nicht.
Es tut nicht das, was es soll: Wenn make durchgelaufen ist, ist nicht
gesagt, daß man ein konsistentes Kompilat hat.
Das soll wohl die Leute dazu bringen, sich OpenBSD zum entwickeln an
OpenSSH zu installieren.
> Bei der diet libc z.B. habe ich so gut wie keine Dependencies auf
> Header-Files drin.
Es mag sein, daß das dort weder notwendig noch wünschenswert ist.
Wenn ich mir vorstelle, was wäre, wenn Projekte wie GCC kein Makefile
hätten...
> Der Enduser wird gewöhnlich an dem Projekt nicht herumdoktorn.
Das mag sein, aber dann kann man doch gleich ausschließlich Binaries
ausliefern.
> Daher ist es um Größenordnungen wichtiger, daß er es sauber bauen kann,
> wenn er nicht herumgepfuscht hat, als dafür zu sorgen, daß er sich nicht
> in den Fuß schießen kann.
Es geht hier nicht um "sauber bauen". Fehlende Dependencies auf
Header-Dateien stehen einer sauberen Kompilierung nicht entgegen (ich
sage ja gar nicht, daß man diese im Kontext von make automatisch
generieren soll), im Gegenteil, sie vergrößern die Menge der Umstände,
unter denen eine saubere Kompilierung möglich ist.
> Dependencies sind trotzdem wichtig, solange ihr Fehlen einem parallelen
> Build im Wege steht.
Oh ja, Du erinnerst mich da an etwas. (Das Makefile für das
Ada-Frontend von GCC müßte dafür komplett neugeschrieben werden.)
Ralf Doering
> > > Welche Methode verwendest Du, um Pfade, Compileroptionen und Libraries
> > > zu bestimmen? Oder compiliert es nur unter genau Deiner Umgebung?
> >
> > $ make prefix=/usr CFLAGS="-Os -pipe"
> >
> > Libraries bestimmen? Bist du besoffen? Das Projekt weiß hoffentlich
> > ohne externe Hilfe, welche Libraries benötigt werden!
>
> Nana, das ist schon netter, klassischer Anwendungsfall für autoconf
> (nicht automake): Feature foo unter Zuhilfe von library bar als compile
> time option implementieren. Je nachdem ob libbar auf dem jeweiligen
> System installiert ist oder nicht wird foo eben unterstützt oder nicht.
> *Das* bekommt man mit make alleine schwerlich hin.
IMO wesentlich wichtiger ist es, herauszubekommen, in welchen
Bibliotheken bestimmte Standardfeatures versteckt sind. Bestes
Beispiel: benötige ich auf dem jeweiligen System ein -lsocket (wie
z.b. unter Solaris) oder ist die gewünschte Funktionalität bereits in
der libc enthalten (z.B. FreeBSD, Linux)?
Für solche Fälle bietet sich entweder autoconf an, oder die Pflege
unterschiedlicher Makefiles für die Zielplattformen.
Ralf
Andreas Ferber
> Reihenfolge zu bearbeiten hat. Es macht durchaus Sinn, das "wie"
> auszugliedern. Ich finde das bei qmail sehr gelungen.
Und ich nicht, aber das ist Geschmacksache.
>> > Woher weißt du das? Für mich sieht das ausgesprochen regelmäßig (will
>> > sagen: generiert) aus und ich habe auch mal ein paar Perl-Scripte
>> > geschrieben, die mit solchen Makefiles arbeiten können.
>> Dann ist die qmail-Distribution unvollständig.
> Wieso das denn?
Der Input des Makefile-Generators fe lt.
> Es kann (und sollte) dir egal sein, wie Bernstein zu seinem Makefile
> kommt. Es funktioniert und ist les- und wartbar. Wäre ja noch schöner,
> wenn jetzt jeder seine IDE bei seinen Paketen mitliefert!
Das braucht er auch nicht. Aber es sind nicht alle Sourcen enthalten.
> Standard ist, daß diese Flags von make benutzt werden.
> Standard ist nicht, wie man welches davon wo zu setzen hat und welche
> Auswirkungen das am Ende hat. Es gibt viele Projekte, bei denen man
> CFLAGS nicht einfach von außen setzen darf, weil das Teil intern
> irgendwo noch -Ihier -Ldort anfügt und das halt nicht tut, wenn man das
> übernagelt hat.
Dann schreib einen Bugreport an den Maintainer. Bei vernünftiger
Verwendung von autoconf tritt übrigens dieses Problem auch nicht auf. An
der geeigneten Stelle ein "override CFLAGS := @CFLAGS@" ins Makefile.in,
und beim Build werden die Environment-CFLAGS zum Zeitpunkt des
configure-Aufrufs verwendet, und auch Ergänzungen sind problemlos im
Makefile oder im configure-Skript möglich.
>> Aber was spricht dagegen, durch Setzen von CC den normalerweise zu
>> verwendenden C-Compiler festzulegen?
> Nichts. Kannst du ja auch tun. Aber halt nicht immer und überall, und
> damit ist es nicht verläßlich und damit praktisch wertlos.
Wenn der Paketmaintainer diesen Mechanismus nicht mutwillig sabotiert,
funktioniert es zuverlässig. Pakete, die sich nicht daran halten, sind
mangelhaft. qmail gehört zu letzteren.
> qmail
> verzichtet daher absichtlich darauf, weil immer wieder Leute CC und
> CFLAGS in ihrem .profile setzen und sich dann über merkwürdige Effekte
> wundern.
Ich übersetze: DJB weiss mal wieder alles besser.
> Nein, aber dann könnte man das leichter warten als im Moment.
> Es passiert mir immer wieder, daß ich irgendwo etwas editiere, weil
> irgendeines dieser lästigen "ich bin schlauer als du" Projekte mal
> wieder Mist gemacht hat, und make findet dann irgendwelche zirkulären
> Dependencies und überschreibt meine Änderung sofort wieder.
PEBKAC. Wenn du nicht bereit bist, dich an die Funktion der verwendeten
Build-Tools zu halten, brauchst du dich nicht wundern, wenn
"merkwürdige Dinge" passieren. Du editierst doch auch nicht
Yacc-generierte C-Sourcen und wunderst dich dann nachher, daß deine
Änderungen verschwunden sind.
> Wer da einen nichttrivialen Graphen in seinem Projekt erzeugt, hat etwas
> falsch gemacht.
Der Graph ist nichttrivial, wenn man nicht einen Teil der Dependencies
weglässt. Letzteres wiederum impliziert, daß make seinen Job nicht
korrekt erfüllen kann, da ihm Informationen fehlen. Man kann sich die
Arbeit aber erleichtern, indem man Dependencies automatisch generieren
lässt.
Leider kann man im Makefile keine Abhängigkeiten ausdrücken, denen
keine Datei zugrundeliegt (Beispiel ar-Archiv <- Liste der enthaltenen
Dateien), wodurch der Graph stets unvollständig bleiben wird.
> Das Makefile der diet libc ist knapp 10k groß, davon ist über die Hälfte
> statische Dependencies. Ein normaler Build erzeugt knapp 700 Dateien
> pro Architektur, doppelt so viele, wenn man die dynamische Version mit
> baut. Klein ist das Projekt also nicht.
Ja. An anderer Stelle schreibst du selbst, daß du fast keine
Dependencies auf Header im Makefile drin hast -> das Makefile ist
unvollständig.
> Ja, make könnte gehörig geschrumpft werden.
Du kannst ja Make.pm (~1200 Zeilen Perl-Code) als Ausgangspunkt nehmen
;-)
>> Kunststück, wenn man keine Libraries ausser der libc verwendet. Das ist
>> aber nicht immer praktikabel.
> Äh, -lsocket -lnsl? -lresolv?
Hmm, ja. Und was tut das Makefile da? Richtig, ausprobieren. Und was
würde autoconf da tun? Wieder richtig, ausprobieren. Wo ist der
Unterschied? (ausser daß qmail nach jedem "make clean" erneut
ausprobiert)
Felix von Leitner
> > > > Solange die Header-Dateien statisch sind und keine Patches ausgeliefert
> >> > werden ist das ja auch in Ordnung.
> >> Findest Du? *Das* gehört doch nun wirklich in die Kategorie
> >> "dysfunktionales Makefile".
> > Wieso? Finde ich nicht.
> Es tut nicht das, was es soll: Wenn make durchgelaufen ist, ist nicht
> gesagt, daß man ein konsistentes Kompilat hat.
Wenn ich die Wahl haben zwischen
a) Dependencies, die mir ständig auf den Fuß fallen
und
b) keine Dependencies
dann wähle ich b). Das ist wenigstens ehrlich. Ich habe in meinem
Leben soweit ich mich erinnern kann zwei Mal Projekte ohne Dependencies
erlebt, die Ärger machten, wenn ich etwas änderte. Aber mir sind
hunderte von Projekten auf den Fuß gefallen, weil die Programmierer
automake und Konsorten nicht im Griff hatten und kaputte, inkonsistente
oder unvollständige Dependencies erzeugten.
> Das soll wohl die Leute dazu bringen, sich OpenBSD zum entwickeln an
> OpenSSH zu installieren.
;)
> > Bei der diet libc z.B. habe ich so gut wie keine Dependencies auf
> > Header-Files drin.
> Es mag sein, daß das dort weder notwendig noch wünschenswert ist.
> Wenn ich mir vorstelle, was wäre, wenn Projekte wie GCC kein Makefile
> hätten...
Das wäre in der Tat wenig erfreulich. Aber letztlich finde ich es sogar
als Gütesiegel, wenn ein Projekt stabil genug ist, daß nicht an
Interfaces herumgebastelt werden muß.
> > Der Enduser wird gewöhnlich an dem Projekt nicht herumdoktorn.
> Das mag sein, aber dann kann man doch gleich ausschließlich Binaries
> ausliefern.
Nein, wieso das denn? Du kannst immer noch den Quellcode lesen, und
immerhin mußt du dich nicht durch verschiedene automacke und autokrampf
Layer durcharbeiten, um zu dem zu wartenden Code durchzustoßen.
Was alleine die #ifdef Orgien von autokrampf für einen
Wartbarkeitsschaden an den diversen Projekten verursacht haben, kann nie
wieder gut gemacht werden.
> Es geht hier nicht um "sauber bauen". Fehlende Dependencies auf
> Header-Dateien stehen einer sauberen Kompilierung nicht entgegen (ich
> sage ja gar nicht, daß man diese im Kontext von make automatisch
> generieren soll), im Gegenteil, sie vergrößern die Menge der Umstände,
> unter denen eine saubere Kompilierung möglich ist.
Full ACK. Wenn ich anständige Header-Dependencies haben kann, will ich
sie ja auch haben. Aber normalerweise hat man subtil kaputte
Dependencies. Siehe z.B. Linux, wo ich mich an grob mindestens 20 Mal
"make clean" erinnere, die ich machen mußte, weil die grandiosen
Dependencies dann doch nicht so sauber funktioniert haben und
irgendwelche kaputten Referenzen irgendwo übrig ließen.
Und da hab ich dann doch lieber keine Dependencies. Da weiß ich
wenigstens, woran ich bin. Aber "Prinzip Hoffnung" verschwendet viel
mehr Zeit als es spart.
Felix
Felix von Leitner
[$CC und $CFLAGS]
> Wenn der Paketmaintainer diesen Mechanismus nicht mutwillig sabotiert,
> funktioniert es zuverlässig. Pakete, die sich nicht daran halten, sind
> mangelhaft. qmail gehört zu letzteren.
> > qmail verzichtet daher absichtlich darauf, weil immer wieder Leute
> > CC und CFLAGS in ihrem .profile setzen und sich dann über
> > merkwürdige Effekte wundern.
> Ich übersetze: DJB weiss mal wieder alles besser.
Andreas, _niemand_ hat ein Problem damit, das zurück zu ändern.
Aber dann subscribest du dich bitte auf die qmail-Mailingliste und
machst den Tech Support. Seit irgendeine Weichbirne RPMs anbietet, die
subtil anders als Default kompiliert sind, sind auf der Mailingliste so
viele Volldeppen aufgeschlagen und haben TOFU, wirklich auffallend dumme
Fragen, Viren und automatische Viren-Warnungen mitgebracht, daß Dan
inzwischen Postings von Outlook Express komplett filtert.
Dan hat keinen Bock, alle Fragenden erstmal eine halbe Stunde nach den
Compiler-Einstellungen, Pfaden und ähnlichem zu interviewen. Wenn du
die hungrige DAU-Meute übernehmen willst, mach bitte einfach eine
Mailingliste auf und ich hoste gerne den Patch für dich, der $CC und
$CFLAGS übernimmt.
> > Nein, aber dann könnte man das leichter warten als im Moment.
> > Es passiert mir immer wieder, daß ich irgendwo etwas editiere, weil
> > irgendeines dieser lästigen "ich bin schlauer als du" Projekte mal
> > wieder Mist gemacht hat, und make findet dann irgendwelche zirkulären
> > Dependencies und überschreibt meine Änderung sofort wieder.
> PEBKAC. Wenn du nicht bereit bist, dich an die Funktion der verwendeten
> Build-Tools zu halten, brauchst du dich nicht wundern, wenn
> "merkwürdige Dinge" passieren. Du editierst doch auch nicht
> Yacc-generierte C-Sourcen und wunderst dich dann nachher, daß deine
> Änderungen verschwunden sind.
Oh, aber natürlich!
Wenn yacc Müll generiert hat, weil diese konkrete Bison-Version im
Skeleton K&R-Prototypen hat und der tolle Uber-Hax0r das mit g++
kompiliert, dann werde ich _nicht_ bison oder das Skeleton debuggen,
sondern das kurz in parser.cc editieren. Und ich erwarte dann, daß das
nicht wieder überschrieben wird, denn parser.cc hängt von source.yacc
ab, nicht umgekehrt, und ist auch noch neuer. Trotzdem passiert es mir
immer wieder, daß irgendwelche Make-Schlaumeier sich in der Komplexität
der von ihnen nicht einmal ansatzweise beherrschten Tools suhlend mit
irgendwelchen zirkulären Dependencies in den Fuß schießen und mir das
meine Änderungen übernagelt.
> > Wer da einen nichttrivialen Graphen in seinem Projekt erzeugt, hat etwas
> > falsch gemacht.
> Der Graph ist nichttrivial, wenn man nicht einen Teil der Dependencies
> weglässt.
Quark.
Projekt dependet auf main.o, support.o und Libraries
Libraries dependet auf quell1.o und quell2.o.
Jedes .o dependet auf ein Source-File welcher Sprache auch immer, das
eventuell auf ein yacc/moc/whatever und ein paar Header dependet.
Das ist ein trivialer Graph, ja sogar ein Baum. Keine Zyklen, keine
gemeinsamen Teilbäume. Kurz: trivial.
> Letzteres wiederum impliziert, daß make seinen Job nicht korrekt
> erfüllen kann, da ihm Informationen fehlen. Man kann sich die Arbeit
> aber erleichtern, indem man Dependencies automatisch generieren lässt.
Unfug. make kann seine Arbeit immer erfüllen, denn seine Arbeit besteht
daraus, Makefile zu lesen, eine Liste von Jobs zu erarbeiten, und diese
Jobs auszuführen, oder eine Fehlermeldung auszugeben und abzubrechen.
Automatisch generierte Dependencies helfen make nicht.
Sie sorgen bloß dafür, daß die richtigen Dateien neu kompiliert werden,
wenn du in irgendeiner Header-Datei herumpfuschst.
> Leider kann man im Makefile keine Abhängigkeiten ausdrücken, denen
> keine Datei zugrundeliegt (Beispiel ar-Archiv <- Liste der enthaltenen
> Dateien), wodurch der Graph stets unvollständig bleiben wird.
?
> Ja. An anderer Stelle schreibst du selbst, daß du fast keine
> Dependencies auf Header im Makefile drin hast
Ja.
> -> das Makefile ist unvollständig.
Nein.
> >> Kunststück, wenn man keine Libraries ausser der libc verwendet. Das ist
> >> aber nicht immer praktikabel.
> > Äh, -lsocket -lnsl? -lresolv?
> Hmm, ja. Und was tut das Makefile da? Richtig, ausprobieren. Und was
> würde autoconf da tun? Wieder richtig, ausprobieren. Wo ist der
> Unterschied?
Ungefähr 200 Kilobyte Bloat-Shell-Script-Scheiße und ungefähr 5 Minuten
Wartezeit auf meinem alten Laptop.
> (ausser daß qmail nach jedem "make clean" erneut ausprobiert)
qmail hat kein "clean" Target.
Felix