[linux-l] Make und Ant (war: Warum gibt es keine einheitliche Dokumentation?)

[Volker Grabsch]

On Thu, Jan 18, 2007 at 12:02:33AM +0100, Steffen Dettmer wrote:
> vim z.B. kann make/gcc Fehler schön
> parsen (leider zeigt er mir immer nur die erste Fehlerzeile an, weiss
> nicht, wie man das korrigiert).

Das Problem hatte ich auch. Recherche im vim-Tutorial ergab: Man kann
zwischen den verschiedenen Fehlern mit
    :cn
und
    :cp
navigieren. Sehr praktisch.

> > > > Ich habe übrigens ein Makefile für meine Java-Sachen geschrieben.
> > > > Gut, damals gab es auch noch kein ant.
> > > 
> > > Ich nehm einfach händische Regeln im automake. Hab auch paar Ideen,
> > > wie man das relativ brauchbar machen könnte, aber dazu hat's dann
> > > noch nicht gereicht. Aber "make distcheck" ist wirklich cool.
> > 
> > Automake, sehr schöne Idee. Obwohl ein handgestricktes Makefile auch
> > nicht der Hit ist, zumal sich javac (bzw. jikes, den ich nehme) ja
> > selbstständig um die Abhängigkeiten kümmert.
> 
> Das javac kümmert sich ziemlich dämlich darum. Es kann z.B. kein
> analogon zu "clean". Aber es ist verdammt schnell. Aber um
> Abhängigkeiten kümmern?
[...]
> Gut, hinkt natürlich, weil ja Java nicht "ganz" kompiliert etc.

Interessante Messwerte. Okay, dann braucht sich javac in der Tat nicht
um die Abhängigkeiten zu kümmern.

> > Wie stehst du eigentlich zu der Frage
> > des Projektes mit mehreren verschachtelten Unterordnern:
> > 
> > a) Jeder Unterordner ein eigenes autonomes Makefile, und "make" rekursiv
> >    aufrufen lassen?
> > 
> > b) Nur ein einziges Makefile, und in den Unterordnern höchstens Include-
> >    Dateien für das Haupt-Makefile.
> > 
> > Siehe auch: http://www.delorie.com/gnu/docs/automake/automake_33.html
> 
> Das ist eine sehr schöne Frage!

> c) Mindestens ein Makefile je SCM Komponente ("Modul", "Package")

Okay, auch eine Methode. Aber doch nur, wenn die Modul *wirklich* in
auch anderen Projekten verwendet werden, richtig?

Innerhalb eines Moduls favorisierst du dann b). Teilst du das Wissen
dann über mehrere Includes auf, oder hast du ein zentrales Makefile
pro Modul?

> Da kann man dann oft sagen: Ein Makefile pro Untermodul. Da man
> Untermodule machen soll (sind schliesslich nur logische
> Verzeichnisstrukturen), hat man oft ein Makefile pro Verzeichnis
> (welches Sourcen enthält).

Geht das nicht etwas zu weit? Ich meine, wenn diese Module sowieso
nur innerhalb des Projektes existieren, wäre doch der Include-Ansatz
viel sinnvoller, oder?

> Daher kann ich recht gut mit der automake-default-Idee leben, dass man
> ein Makefile pro Verzeichnis hat.
[...]
> Verwendet man (nur, moderene, GNU-) Makefiles, kann man natürlich auch
> sehr viel in make programmieren :) Auch includen etc. Allerdings legt
> man sich da auch schnell die Karten (wenn man Makefiles automatisch
> erzeugen muss). Da gibts eine Million Fallen. Mit automake haben wir es
> zumindestens mit neueren Versionen immer irgendwie hingekriegt.

Moment. Mit scheint, du übersiehst die Möglichkeit, dass Automake auch
selbst andere Automake-Dateien includen kann. Das heißt, Ansatz b)
spielt doch super mit Automake, wie auch in dessen Infopage beschrieben.

[Projekt "make-crontab"]
> >     https://ds.m-click.de/svn/m-click/make-crontab/trunk/
> 
> Das Makefile mit der einen Regel "$(RESULT): $(SOURCES) Makefile" (wenn
> man von dist mal absieht)? Das geht doch in bash genauso, wenn man ein
> test -nt vormacht, oder?

Nicht ganz. Ich müsste jede einzelne Crontab-Datei erstmal überprüfen.
Ist im Shell-Script etwas umständlich. Dies als Makefile-Regel hingegen
versteht jeder sofort.

> Da könnte man vielleicht noch bissel was machen, wenn man pattern
> definieren kann. Also z.B. (ungetestet, bin mir bei $< und so nicht
> sicher):
> 
> SOURCES = $(wildcard crontab-*.src)
> HELPERS = $(patsubst %.src, %.tmp, $(SOURCES))
> 
> $(RESULT): $(HELPERS) Makefile
> 	cat $(HELPERS) > $@
> 	crontab $@
> 
> %.tmp: %.src
> 	NAME=`echo "$$FILE" | sed "s,^crontab-,,"` ; \
> 	... usw ...
> 	sed "s, at NAME@,$$NAME,g ; s, at PWD@,$(REAL_PWD),g" \
> 	# irgendwie $< statt $$FILE oder so:
> 	$< > $@

Interessanter Ansatz. Das würde ich machen, wenn die Bash keine
for-Schleife hätte. Aber wo liegt der Vorteil?

Leichter verständlich ist es nicht wirklich, und er erzeugt viel
mehr temporäre Dateien im Verzeichnis. Performance wird auch nicht
gespart, da der "crontab"-Aufruf die meisten Resourcen frisst.

Worin siehst du den Vorteil dieser Variante?

> > > Diese tollen ant "tasks" sind IMHO eine Krankheit. Es gibt eine jar und
> > > ein unjar task. Gut, make kommt mit Regeln, die viele Ausgaben erzeugen
> > > auch nicht sooo einfach klar (bzw. der Mensch, der es nutzt nicht ;)),
> > > aber es geht.
> > 
> > Man kann es mit ein wenig Mühe stark verbessern. Schade, dass es
> > automake noch nicht kann. 
> 
> Was, jar? Kann es:
> [...]

Du hast mich falsch verstanden: Es ging mir um die Text-Ausgabe von Make
für den Menschen.

Man wird bei jedem Build mit elendig langen Compiler-Aufrufen genervt.
Das Makefile des Linux-Kernel hingegen sagt einfach nur:

    CC  bla.c
    CC  bla2.c
    LN  ...

Sowas ist schön und übersichtlich. Im normalen Makefile durch Neudefinieren
von $(CC) und co. möglich, und selbst wenn das kompliziert wäre: Automake
müsste das dann können, und sei es nur, indem es sowas wie

bla.o: bla.c
    @echo CC  bla.c
    @gcc -c bla.c

produziert. Man muss nur sicherstellen, dass im Fehlerfall der gesamte
Befehl erscheint, nicht nur "CC  ..irgendwas.."  ... oder dass man
dieses Verhalten durch eine Umgebungsvariable steuern kann:

    $ make bla.o
        CC  bla.c

    $ make bla.o DEBUG=1
    gcc -c bla.c

Ich hoffe, du weißt nun, was ich meine.

> > Seit ich das gesehen habe, bemühe ich mich ebenfalls, in Makefiles und
> > Shell-Scripten für eine übersichtliche Ausgabe zu sorgen. Er bei
> > wirklichen Fehlern braucht man Details.
> 
> Ja, da helfen aber auch Tools.

Das schon. Dennoch möchte ich alles, was gut gegangen ist,
*übersichtlich* dargestellt bekommen. Das hat wirklich enorme Vorteile.
Ich habe festgestellt, dass diesen Zusatzaufwand mit den Silent-Optionen
und echo-Befehlen im Nachhinein richtig Zeit spart. Weil man eben viel,
viel schneller sieht, was los ist.

Das ähnelt etwas der Diskussion über transparente Shells. Klar sieht das
cooler aus. Genauso wie es cool aussieht, wenn ein make-Aufruf den
ganzen Bildschirm voller Text malt. Praktikabel ist es aber nicht,
sondern kontraproduktiv.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR