makefile regel
Jens Frederich
man kann ja rules in einem makefile angeben das .c files
in .o files umgewandelt werden.
z.B. so :
.c.o:
$(CC) $(CFLAGS) \
-c -o $*.o $<
das funktioniert aber nur wenn die .c files im working directory
liegen. Wie kann ich das rules veraendern so das die sourcefiles
in einem bestimmte directory gesucht werden.
z.B. : ../src
Jens
Jan Schaumann
> Wie kann ich das rules veraendern so das die sourcefiles
> in einem bestimmte directory gesucht werden.
> z.B. : ../src
man google
http://www.gnu.org/manual/make-3.79.1/html_mono/make.html#SEC26
Im Allgemeinen willst du das aber nicht - nutze statt dessen lieber
rekursive Makefiles.
-Jan
--
Jan Schaumann <http://www.netmeister.org>
"You just come along with me and have a good time. The Galaxy's a
fun place. You'll need to have this fish in your ear."
Torsten Mohr
unter GNU make:
VPATH = ../src
> liegen. Wie kann ich das rules veraendern so das die sourcefiles
> in einem bestimmte directory gesucht werden.
> z.B. : ../src
Abhängigkeiten direkt eintragen müsste auch funktionieren:
file.o : ../src/file.c file.h
main.o : main.c ../include/main.h
Jens Frederich
>
> Abhängigkeiten direkt eintragen müsste auch funktionieren:
>
> file.o : ../src/file.c file.h
> main.o : main.c ../include/main.h
das habe ich auch gemacht.
z.B. :
main.o. ../src/main.o
$(CC) $(CFLAGS) \
-c $?
das ist auch ok so. Wie sieht die Regel fuer
alle *.o files in dem Directory ../src aus ?
Ansonsten muss ich das ja fuer jedes objekt file machen.
Jens
Werner Jakobi
>das habe ich auch gemacht.
>z.B. :
Du versuchst gegen die inbuilt-rules zu kämpfen und das ist falsch.
Die inbilt-rules funktionieren für c/cpp-files so gut, daß man sie,
zumindest als Anfänger nicht überfahren muß.
In einem Makefile mußt du Abhängigkeiten beschreiben.
Fang an mit ein paar Variablen:
TARGET=MyProg
OBJ_1_DIR=../anywhere
OBJ_2_DIR=../elsewhere
TOBJ1=$(OBJ_1_DIR)/main.o\
$(OBJ_1_DIR)/misc.o
TOBJ2=$(OBJ_2_DIR)/mytcp.o\
$(OBJ_2_DIR)/mysocket.o
Jetzt kommen die Depencies:
$(TARGET): $(TOBJ1) $(TOBJ2)
Schlichter gehts eigentlich nicht. Um die Regel $(TARGET) zu erfüllen
müssen die in $(TOBJ1) und $(TOBJ2) aufgeführten Objekte vorhanden und
entsprechend der inbuilt-rules up-to-date sein.
Wenn deine Regel Sonderbehandlung braucht, kannst du ihr diese durch
\tAnweisung
\t...
unter der Zeile mit den Abhängigkeiten mitgeben.
Viel mehr muß man für den Anfang von Makefiles eigentlich nicht
wissen.
Ach ja, irgendwo ein
all: $(TARGET)$(GUISUFF)$(EXESUFF)
wirkt Wunder.
Gruss, Werner
--
Morver, der Rollstuhl fuer kranke Windows-Newsreader und fuer OE.
Aktuelle Version 1.0.303: http://werner.jakobi.bei.t-online.de/
Peter J. Holzer
Kommt darauf an, wie portabel das ganze sein muss:
Mir ist keine Lösung bekannt, die mit allen Make-Versionen funktioniert.
Wenn das notwendig ist, wirst Du nicht umhin kommen, für jedes File eine
eigene Regel ins Makefile zu schreiben (läßt sich natürlich über
Scripts automatisieren).
Viele Make-Versionen kennen eine Variable VPATH, in der man zusätzliche
Source-Directories spezifizieren kann. In dem Fall also einfach
VPATH=../src
setzen.
GNU make erlaubt außerdem, sogenannte "pattern rules" zu schreiben. In
dem Fall würde das so aussehen:
../src/%.c: %.o
$(CC) $(CFLAGS) -c -o $@ $<
IMHO die lesbarste Lösung, leider aber auch die am wenigsten portable.
hp
--
_ | Peter J. Holzer |
|_|_) | Sysadmin WSR | In case of emergency break laws of physics.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Stephen Baxter
Erich Frühstück
Um dir diese Arbeit zu sparen, kannst du einen Makefile-Generator
einsetzen. Da gibt es verschiedene Ansätze. EFEU (-> Signatur)
enthält ein tool, mit dem aus einem beliebigen Source-Baum ein
Makefile generiert wird (Zweistufig: zuerst ein Imakefile und dann
mit einem zu xmkmf äquivalenten Kommando ein Makefile).
Abhängigkeiten werden automatisch ermittelt. Zusatzregeln in
Abhängigkeit von Filezusaätzen können spezifiziert werden
(Für Konfigurationsdateien. manpages, ....). Das Makefile wird
automatisch upgedated, sobald eine neue Datei dem Sourcebaum
hinzugefügt wird.
PS: In EFEU ist das Bildungsverzeichnis (hier werden von make
generierte Dateien abgelegt) vollständig von den Sourcen getrennt.
Grüße
Erich
--
EFEU is great (development tools, C libraries, interpreter language, ...).
Get the open source from http://efeu.cybertec.at now.
Jens Schweikhardt
in <slrna8kj2e....@www.netmeister.org>:
...
# Im Allgemeinen willst du das aber nicht - nutze statt dessen lieber
# rekursive Makefiles.
Im Allgemeinen ist rekursives make böse und man will das nicht.
Siehe Peter Millers "Recursive Make Considered Harmful",
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
Wenn man dann noch nicht-rekursives make mit Advanced Auto-Dependency
Generation (http://www.paulandlesley.org/gmake/autodep.html) kombiniert,
kommt man auch mit riesigen Sourcebäumen zurecht, wo die Objektdateien
und Dependencies nicht in den Quellverzeichnissen liegen (auch ohne den
notorisch undurchsichtigen und unportablen VPATH) und bekommt obendrein
einen riesigen Geschwindigkeitsvorteil, weil nicht für jedes Verzeichnis
ein make Prozeß gestartet werden muß. Wenn's nichts zu tun gibt, braucht
ein rekursives make u.U. minutenlang; ein nichtrekursives ist quasi
sofort fertig (Bruchteile von CPU Sekunden, selbst bei mehrern Hundert
Dateien).
Regards,
Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
Torsten Mohr
>> main.o : main.c ../include/main.h
> das habe ich auch gemacht.
> z.B. :
>
> main.o. ../src/main.o
> $(CC) $(CFLAGS) \
> -c $?
>
> das ist auch ok so. Wie sieht die Regel fuer
> alle *.o files in dem Directory ../src aus ?
> Ansonsten muss ich das ja fuer jedes objekt file machen.
Hallo Jens,
nee, so war das nicht gemeint, also ich mach immer einen
Teil im Makefile mit den allgemeinen Regeln, a la:
%.o : %.c
$(CC) ...
Da sind gar keine einzelnen Dateinamen drin.
Und dann einen Teil, in dem die einzelnen Abhängigkeiten
drin sind, z.B. so wie oben der Teil:
file.o: file.c file.h common.h usw.
main.o: main.c file.h common.h main.h
Diese einzelnen Abhängigkeiten kann man einzeln eingeben und pflegen,
aber auch erzeugen lassen (hab ich mal ein Perlskript für geschrieben),
der gcc kann mit Option "-M" aber auch die Abhängigkeiten der Quelldateien
erzeugen lassen.
Damit kann man dann auch ein Makefile erzeugen, das seine Abhängigkeiten
bei Bedarf selbst erzeugt.
Viele Grüsse,
Torsten.
Michael Herrmann
Torsten Mohr wrote:
> ...
> der gcc kann mit Option "-M" aber auch die Abhängigkeiten der Quelldateien
> erzeugen lassen.
> ...
besser -MM, ist übersichtlicher :-)
gruß
micha
--
This message contains 100% pure brain dump. Nobots: Remove
the letter l from my email address.
Felix von Leitner
> Um dir diese Arbeit zu sparen, kannst du einen Makefile-Generator
> einsetzen. Da gibt es verschiedene Ansätze. EFEU (-> Signatur)
> enthält ein tool, mit dem aus einem beliebigen Source-Baum ein
> Makefile generiert wird (Zweistufig: zuerst ein Imakefile und dann
> mit einem zu xmkmf äquivalenten Kommando ein Makefile).
Aus der Kategorie "Software, die die Welt nicht braucht" kommt heute:
EFEU! Die geradezu existenzialistische Wichtigkeit von EFEU kann nicht
genug unterstrichen werden und erreicht schon fast die Klasse des
Dauerbrenners "bsh"... 8-0
> Abhängigkeiten werden automatisch ermittelt.
Unglaublich!
Der Innovationswucht von EFEU kann man ja kaum standhalten!
Das ist ja fast so neuartig und nie vorher gesehen wie die diversen
Microsoft Innovationen.
> Zusatzregeln in Abhängigkeit von Filezusaätzen können spezifiziert
> werden (Für Konfigurationsdateien. manpages, ....). Das Makefile wird
> automatisch upgedated, sobald eine neue Datei dem Sourcebaum
> hinzugefügt wird.
Ein Wunder! Ein Wunder! Hallelujah!
Felix von Leitner
> Wenn man dann noch nicht-rekursives make mit Advanced Auto-Dependency
> Generation (http://www.paulandlesley.org/gmake/autodep.html) kombiniert,
> kommt man auch mit riesigen Sourcebäumen zurecht,
Du wirst lachen, man kommt zurecht, ohne die Dependencies advanced auto
erzeugen zu lassen.
Felix
Erich Frühstück
wrote:
Hast du dir EFEU überhaupt angesehen?
Wenn ja, dann komm mal mit einer inhaltlichen Kritik!
Du agierst wie ein Theaterkritiker der einen Verriss über ein
nicht gesehenes Stück schreibt, nur weil ihm die Nase des
Autors nicht passt.
Für dich scheinen die folgenden Grundsätze zu gelten:
1.) Felix hat immer Recht.
2) Wer Felix kritisiert muss ein Trottel sein.
Und schau mal aus deinem Elfenbeinturm raus und lies mal
etwas über Cliquen/Sekten, Sprache als Abgrenzung nach außen und
äußere Feindbilder zur Stabilisierung des Gruppenzusammenhalts.
Peter J. Holzer
> Wenn man dann noch nicht-rekursives make mit Advanced Auto-Dependency
> Generation (http://www.paulandlesley.org/gmake/autodep.html) kombiniert,
Der Artikel war mir neu (obwohl er offenbar schon recht alt ist: "If you
have a fairly recent version of GCC, you can use the -MD option"? Muß
mindestens 8 oder 9 Jahre her sein), aber eine ähnlich Technik verwende
ich auch seit langem. Allerdings habe ich sie nach komplizierteren
Anfängen ziemlich abgespeckt:
CFLAGS += -MD
...
-include *.d
Begründung:
Beim ersten make-Aufruf existieren noch gar keine .o-Files, es müssen
also alle Source-Files compiliert werden. Dabei werden die .d-Files
automatisch erzeugt. Wenn ich nun an einem der Source-Files (.c oder .h)
etwas ändere, werden durch die Compilierung wieder genau die richtigen
.d-Files upgedatet (die prerequisites für jedes .o und das zugehörige .d
sind ja gleich)
Das funktioniert nur in zwei Fällen nicht:
1) Man löscht ein .h-File. Dafür wird aber auch in dem Artikel keine
Lösung vorgeschlagen, In der Praxis war das bei mir noch nie ein
Problem, weil ich normalerweise alle #includes entfernt und neu
compiliert und getestet habe, bevor ich das File endgültig lösche -
damit stimmen die Dependencies zu diesem Zeitpunkt wieder. Wenn
mehrere Leute über CVS zusammenarbeiten, kann das allerdings durchaus
passieren.
2) Man löscht .d-Files, ohne die zugehörigen .o-Files zu löschen. Das
dürfte wohl meistens eine Folge von 1) sein. In diesem Fall würde
eine explizite Regel zur Erzeugung eines .d-Files helfen. Oder man
löscht eben .d-Files nicht händisch, sondern entweder mit einem
Make-Target, das auch die .o-Files löscht (make distclean) oder
mittels eines Scripts, das z.B. alle .d-Files sucht, in denen ein
bestimmtes header File referenziert wird und dann .d-File und .o-File
löscht.
Das *.d oben funktioniert natürlich nur, wenn alle Targets im gleichen
Directory sind, also bei Single-Directory-Projekten oder mit rekursivem
make. Ansonsten ist es durch $(OBJS:.c=.d) zu ersetzen.
Jens Schweikhardt
in <slrna8rm9l.c...@teal.h.hjp.at>:
#
# On 2002-03-11 10:01, Jens Schweikhardt <use...@schweikhardt.net> wrote:
#> Wenn man dann noch nicht-rekursives make mit Advanced Auto-Dependency
#> Generation (http://www.paulandlesley.org/gmake/autodep.html) kombiniert,
#
# Der Artikel war mir neu (obwohl er offenbar schon recht alt ist: "If you
# have a fairly recent version of GCC, you can use the -MD option"? Muß
# mindestens 8 oder 9 Jahre her sein), aber eine ähnlich Technik verwende
# ich auch seit langem. Allerdings habe ich sie nach komplizierteren
# Anfängen ziemlich abgespeckt:
#
# CFLAGS += -MD
#
# ...
#
# -include *.d
#
# Begründung:
#
# Beim ersten make-Aufruf existieren noch gar keine .o-Files, es müssen
# also alle Source-Files compiliert werden. Dabei werden die .d-Files
# automatisch erzeugt. Wenn ich nun an einem der Source-Files (.c oder .h)
# etwas ändere, werden durch die Compilierung wieder genau die richtigen
# .d-Files upgedatet (die prerequisites für jedes .o und das zugehörige .d
# sind ja gleich)
#
# Das funktioniert nur in zwei Fällen nicht:
#
# 1) Man löscht ein .h-File. Dafür wird aber auch in dem Artikel keine
# Lösung vorgeschlagen, In der Praxis war das bei mir noch nie ein
# Problem, weil ich normalerweise alle #includes entfernt und neu
# compiliert und getestet habe, bevor ich das File endgültig lösche -
# damit stimmen die Dependencies zu diesem Zeitpunkt wieder. Wenn
# mehrere Leute über CVS zusammenarbeiten, kann das allerdings durchaus
# passieren.
Hier verstehe ich das genaue Problem noch nicht. Wenn man einen *.h File
bar.h löscht, beschwert sich der Compiler (foo.c: bar.h not found). Man
muß den entsprechenden C File foo.c anfassen und dann werden wieder
sowohl foo.o als auch foo.d erneuert. (Wer mehrere gleichnamige Header
in verschiedenen Verzeichnissen hat, die auch noch per -I für alle
Übersetzungen abgesucht werdem, sollte mal über sein Design nachdenken.)
# 2) Man löscht .d-Files, ohne die zugehörigen .o-Files zu löschen. Das
# dürfte wohl meistens eine Folge von 1) sein. In diesem Fall würde
# eine explizite Regel zur Erzeugung eines .d-Files helfen. Oder man
# löscht eben .d-Files nicht händisch, sondern entweder mit einem
# Make-Target, das auch die .o-Files löscht (make distclean) oder
# mittels eines Scripts, das z.B. alle .d-Files sucht, in denen ein
# bestimmtes header File referenziert wird und dann .d-File und .o-File
# löscht.
In der Tat, wenn man den foo.d entfernt *und* eine dort aufgeführte
Dependency bar.h von foo.c ändert, dann sagt make fälschlicherweise
foo.o is up-to-date. Aber das ist in gewissen Sinne äquivalent zum
Entfernen des Makefiles (oder Teilen daraus). Da kann auch make nichts
für. :-)
Bernhard Trummer
> Hier verstehe ich das genaue Problem noch nicht. Wenn man einen *.h File
> bar.h löscht, beschwert sich der Compiler (foo.c: bar.h not found). Man
> muß den entsprechenden C File foo.c anfassen und dann werden wieder
> sowohl foo.o als auch foo.d erneuert.
Nein, weil das alte foo.d im Makefile includiert wird, um die
Dependencies für foo.o festzustellen. Und dort stehen immer noch die
gelöschten h-Files drinnen. D.h., das .o-File kann nicht compiliert
werden, weil einige der Dependencies (bar.h) nicht erfüllt sind.
Und damit kann auch kein neues foo.d-File erzeugt werden.
--
No sig @ work.
Bernd Petrovitsch
>Nein, weil das alte foo.d im Makefile includiert wird, um die
>Dependencies für foo.o festzustellen. Und dort stehen immer noch die
>gelöschten h-Files drinnen. D.h., das .o-File kann nicht compiliert
>werden, weil einige der Dependencies (bar.h) nicht erfüllt sind.
>Und damit kann auch kein neues foo.d-File erzeugt werden.
Wobei man das Problem insbesondere dann hat, wenn man CVS verwendet.
Da verschwinden schon mal einfach so .c oder .h Files. Die einzige
vollautomatische Recoverymöglichkeiten sind entweder den CVS output
parsen und bei "R x.c" x.[do] auch löschen oder gleich alle .d
löschen.
Bernd
--
Bernd Petrovitsch Email : be...@gams.at
g.a.m.s gmbh Fax : +43 1 205255-900
Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe
LUGA : http://www.luga.at
Felix von Leitner
Das Betrachten deines ehrfurchteinflößenden Webseiten-Klumpens reicht
zur Bewertung der Software. Die Kritik war nicht, daß EFEU nichts taugt
oder besonders schlecht implementiert ist, sondern daß es nichts löst,
das nicht schon andere gelöst hätten. Deine Webseiten sind im Übrigen
spektakulär schlecht darin, zu erläutern, wieso man sich mit deiner
Software überhaupt beschäftigen sollte.
Deine Dokumentation sieht genau so aus, wie man sich das für automatisch
generierte Dokumentation vorstellt: unsortiert, unsammenhängend, unklar,
unbrauchbar. Das sieht aus wie deine persönlich Abrechnung mit deinem
Informatiklehrer: alle Altlasten aus der Zeit, wo du noch nicht wußtest,
was du tatest, in einem monumentalen Bitberg. Kurz um: Software, die
die Welt nicht braucht.
> Wenn ja, dann komm mal mit einer inhaltlichen Kritik!
Das _war_ eine inhaltliche Kritik.
> Du agierst wie ein Theaterkritiker der einen Verriss über ein
> nicht gesehenes Stück schreibt, nur weil ihm die Nase des
> Autors nicht passt.
I didn't like the play, but I saw it under adverse conditions.
The curtain was up.
> Für dich scheinen die folgenden Grundsätze zu gelten:
> 1.) Felix hat immer Recht.
Sagen wir: meistens.
> 2) Wer Felix kritisiert muss ein Trottel sein.
Die Korrelation ist in der Tat erschreckend groß.
> Und schau mal aus deinem Elfenbeinturm raus und lies mal
> etwas über Cliquen/Sekten, Sprache als Abgrenzung nach außen und
> äußere Feindbilder zur Stabilisierung des Gruppenzusammenhalts.
Warum machst du nicht ab jetzt Vollzeit-Soziologie und läßt uns mit
deinem Code in Ruhe? Es besteht ja offenbar begründbarer Verdacht, daß
du dich damit besser auskennst (auch wenn das ja offenbar keine
sonderlich starke Aussage ist).
--
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it.
--Groucho Marx
Erich Frühstück
wrote:
> Thus spake Erich Frühstück (e...@synthesis.co.at):
>> Hast du dir EFEU überhaupt angesehen?
>
> Das Betrachten deines ehrfurchteinflößenden Webseiten-Klumpens reicht
> zur Bewertung der Software. Die Kritik war nicht, daß EFEU nichts taugt
> oder besonders schlecht implementiert ist, sondern daß es nichts löst,
> das nicht schon andere gelöst hätten. Deine Webseiten sind im Übrigen
> spektakulär schlecht darin, zu erläutern, wieso man sich mit deiner
> Software überhaupt beschäftigen sollte.
Gut. Mit dieser Kritik kann ich etwas anfangen. An den Webseiten
habe ich noch einiges zu tun. Nur in einem Punkt gebe ich dir
Unrecht: Eine Software nicht zu verwenden, nur weil das Problem
schon von einder anderen Software gelöst wurde ist kein Argument.
Denn die Lösung ist anders. Welche Lösung jetzt besser ist,
kann nicht ohne Vergleich festgestellt werden und hängt von
individuellen Anforderungen und Bedürfnissen ab.
> Deine Dokumentation sieht genau so aus, wie man sich das für automatisch
> generierte Dokumentation vorstellt: unsortiert, unsammenhängend, unklar,
> unbrauchbar. Das sieht aus wie deine persönlich Abrechnung mit deinem
> Informatiklehrer: alle Altlasten aus der Zeit, wo du noch nicht wußtest,
> was du tatest, in einem monumentalen Bitberg. Kurz um: Software, die
> die Welt nicht braucht.
Kleider machen Leute und offensichtlich machen Webseiten
Programme. Der Schwerpunkt in der Formatierung liegt zur Zeit
bei LaTeX (wird für die Produktion von Berichten benötigt),
der HTML-Treiber hat niedrige Priorität. Ein Vergleich mit den
PostScript-Versionen lohnt sich.
Ich dachte mir, lieber vollständige, aber teilwese
knappe Referenzen, als ausgwählte, gut ausformulierte Texte
zu veröffentlichen, aber das kommt offensichtlich nicht immer
gut an.
Das Flagschiff von EFEU ist esh (Ein Interpreter mit C/C++
ähnlicher Syntax, steht auch in Form von Bibliotheksfunktionen
zur Verfügung). Ich werde dieses Kommando mehr
in den Vordergrund stellen.
Bernhard Trummer
> vollautomatische Recoverymöglichkeiten sind entweder den CVS output
> parsen und bei "R x.c" x.[do] auch löschen oder gleich alle .d
> löschen.
Alle .d-Files zu löschen ist eher eine schlechte Idee.
Weil wenn sich als nächstes ein Header ändern sollte, werden
darauf basierende .c-Files nicht neu compiliert...
Bernd Petrovitsch
Die werden nachhar vollautomatisch wieder angelegt (wie es auch passiert,
wenn ein File neu dazukommt un d zum erstenmal ausgecgheckt wird).
Oder hab ich was übersehen ?
Bernhard Trummer
> Die werden nachhar vollautomatisch wieder angelegt
Nein. Ein .d-File wird nur angelegt bzw. aktualisiert, wenn das
dazugehörige .c-File compiliert wird.
(Wir reden ja immer noch von der gcc-Option -MD, oder?)
Bernd Petrovitsch
In _dem_ Fall wohl schon.
Ich oben vom (Standard-?)Fall geschrieben, wo die .d Files mit
expliziten Regeln (wie in `info make` beschrieben) angelegt
werden.
den gcc-MD Fall müßte man eigentlich geeignet aufbohren können ...
Felix von Leitner
> Programme.
Deine Webseite muß zuallererst die Frage klären: "wieso sollte ich mir
das hier alles durchlesen?"
> Das Flagschiff von EFEU ist esh (Ein Interpreter mit C/C++
> ähnlicher Syntax, steht auch in Form von Bibliotheksfunktionen
> zur Verfügung). Ich werde dieses Kommando mehr
> in den Vordergrund stellen.
Wozu braucht man das?
Es gibt auf Freshmeat Tonnen von einbaubaren Script-Sprachen und
Interpretern. Wenn du als Autor nicht mal motivieren kannst, wieso man
deine Lösung einsetzen sollte, dann wird das niemand einsetzen. Dann
hättest du dir die Veröffentlichung auch ganz sparen können.
Felix
Klaus von der Heyde
> Das Betrachten deines ehrfurchteinflößenden Webseiten-Klumpens reicht
> zur Bewertung der Software. Die Kritik war nicht, daß EFEU nichts taugt
> oder besonders schlecht implementiert ist, sondern daß es nichts löst,
> das nicht schon andere gelöst hätten.
Das ist doch nicht so schlimm. Manchen mag dieses projekt eher zusagen
als anderes. Wenn jemand EFEU nutzen will, warum nicht? Es ist ja
niemand gezwungen, sich damit zu beschaeftigen.
> Deine Webseiten sind im Übrigen
> spektakulär schlecht darin, zu erläutern, wieso man sich mit deiner
> Software überhaupt beschäftigen sollte.
Das stimmt allerdings.
Klaus
Michael Strauss
> # Im Allgemeinen willst du das aber nicht - nutze statt dessen lieber
> # rekursive Makefiles.
>
> Im Allgemeinen ist rekursives make böse und man will das nicht.
> Siehe Peter Millers "Recursive Make Considered Harmful",
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
Hat den Nachteil gmake vorauszusetzen.
Frage: Sollte man das tun? (gmake voraussetzen)
>
> Wenn man dann noch nicht-rekursives make mit Advanced Auto-Dependency
> Generation (http://www.paulandlesley.org/gmake/autodep.html) kombiniert,
> kommt man auch mit riesigen Sourcebäumen zurecht, wo die Objektdateien
> und Dependencies nicht in den Quellverzeichnissen liegen (auch ohne den
> notorisch undurchsichtigen und unportablen VPATH) und bekommt obendrein
> einen riesigen Geschwindigkeitsvorteil, weil nicht für jedes Verzeichnis
> ein make Prozeß gestartet werden muß. Wenn's nichts zu tun gibt, braucht
> ein rekursives make u.U. minutenlang; ein nichtrekursives ist quasi
> sofort fertig (Bruchteile von CPU Sekunden, selbst bei mehrern Hundert
> Dateien).
Das setzt zusätzlich noch gcc und sed voraus.
Michael
Jens Schweikhardt
in <slrna8qnrb...@spraitbach.wieslauf.sub.de>:
#
# Jens Schweikhardt wrote:
#> # Im Allgemeinen willst du das aber nicht - nutze statt dessen lieber
#> # rekursive Makefiles.
#>
#> Im Allgemeinen ist rekursives make böse und man will das nicht.
#> Siehe Peter Millers "Recursive Make Considered Harmful",
#> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
#
# Hat den Nachteil gmake vorauszusetzen.
# Frage: Sollte man das tun? (gmake voraussetzen)
Ja, anstatt portable Makefiles zu schreiben, sollte man lieber ein
portables make benutzen. Macht das Leben um so viel einfacher. Siehe
Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
[Dependency Ermittlung]
# Das setzt zusätzlich noch gcc und sed voraus.
Oder jedes andere Werkzeug, das Dependencies ermitteln und anschließend
massieren kann (wir benutzen gcc und perl). Niemand hat gesagt, daß eine
gute und robuste Engineering-Lösung umsonst zu haben ist. Bei uns
funktioniert sie prächtig und hat die Produktivität deutlich gesteigert:
die rekursiven builds haben bis zu einer Stunde gedauert; jetzt geht es
in 10 Minuten. Niemand macht mehr `make clean all' weil er den
Dependencies oder dem Makefile Autor nicht traut.
Gunnar Ritter
> Ja, anstatt portable Makefiles zu schreiben, sollte man lieber ein
> portables make benutzen.
Nein, sollte man nicht, wenn die Software allgemein beliebt werden
soll. Unportable Makefiles sind oft Anlaß genug, einen weiten Bogen
um das ganze Programm zu machen. Sie haben den Beigeschmack von »Mein
Programmierer hat einen beschränkten Horizont und ist egozentrisch«
und »Die Software selbst wird auch nicht recht portabel sein«.
> Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
Toll, der Maintainer betreibt Advocacy für sein Programm. Das kann
man ihm natürlich nicht verübeln, aber richtig ernstnehmen kann man
es ebensowenig.
Gunnar
Jens Schweikhardt
in <3C924BEB...@bigfoot.de>:
#
#> Ja, anstatt portable Makefiles zu schreiben, sollte man lieber ein
#> portables make benutzen.
#
# Nein, sollte man nicht, wenn die Software allgemein beliebt werden
# soll.
Selbst dann, denn das "allgemein beliebt" werden hängt nicht davon ab,
ob gmake benutzt wird, oder nicht, sondern ob die SW brauchbar ist.
Größere SW Pakete haben heutzutage schon so viele Abhängigkeiten von
anderen Paketen (erfordern jpeg, tcl, perl, python, ...), da ist
gmake die am wenigsten kritische. Ein Blick auf die BSD ports in der
Kategorie devel von a bis d:
sje2bk@bk4957:/usr/ports/devel
$ grep USE_GMAKE */Makefile
ORBit/Makefile:USE_GMAKE= yes
SN/Makefile:USE_GMAKE= yes
a2dev/Makefile:USE_GMAKE= defined
adabroker/Makefile:USE_GMAKE= yes
allegro/Makefile:USE_GMAKE= yes
anjuta/Makefile:USE_GMAKE= yes
arm-aout-binutils/Makefile:USE_GMAKE= yes
arm-aout-gcc295/Makefile:USE_GMAKE= yes
arm-elf-binutils/Makefile:USE_GMAKE= yes
asis/Makefile:USE_GMAKE= yes
asmutils/Makefile:USE_GMAKE= yes
autogen/Makefile:USE_GMAKE= yes
avr-binutils/Makefile:USE_GMAKE= yes
avr-gcc/Makefile:USE_GMAKE= yes
avr-libc/Makefile:USE_GMAKE= yes
binutils-m68k/Makefile:USE_GMAKE= yes
bonobo-conf/Makefile:USE_GMAKE= yes
bonobo/Makefile:USE_GMAKE= yes
bugbuddy/Makefile:USE_GMAKE= yes
c2lib/Makefile:USE_GMAKE= yes
cc65/Makefile:USE_GMAKE= yes
cccc/Makefile:USE_GMAKE= yes
cervisia/Makefile:USE_GMAKE= yes
cflow/Makefile:USE_GMAKE= yes
clanlib/Makefile:USE_GMAKE= yes
clint/Makefile:USE_GMAKE= yes
codecrusader/Makefile:USE_GMAKE= yes
codemedic/Makefile:USE_GMAKE= yes
commoncpp/Makefile:USE_GMAKE= yes
cppadvio/Makefile:USE_GMAKE= yes
crossgo32/Makefile:USE_GMAKE= yes
cxref/Makefile:USE_GMAKE= yes
ddd/Makefile:USE_GMAKE= yes
dia2code/Makefile:USE_GMAKE= yes
dmake/Makefile:USE_GMAKE= yes
doc++/Makefile:USE_GMAKE= yes
dotconf/Makefile:USE_GMAKE= yes
doxygen/Makefile:USE_GMAKE= yes
# Unportable Makefiles sind oft Anlaß genug, einen weiten Bogen
# um das ganze Programm zu machen. Sie haben den Beigeschmack von »Mein
# Programmierer hat einen beschränkten Horizont und ist egozentrisch«
# und »Die Software selbst wird auch nicht recht portabel sein«.
Wer solche Annahmen macht, verallgemeinert aus einem Einzelfall (welchem
übrigens?) und hat nicht verstanden, um was es geht.
#> Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
# Toll, der Maintainer betreibt Advocacy für sein Programm.
gmake ist nicht das Programm von Smith; lies die erste Seite.
# Das kann
# man ihm natürlich nicht verübeln, aber richtig ernstnehmen kann man
# es ebensowenig.
Ich halte es da eher mit der Kompetenz derjenigen, die die entsprechenden
Aussagen machen, und da rangiert Smith unangefochten an der Spitze. Daß
ein Maintainer sein Programm empfiehlt, gehört dazu. Täte er's nicht,
wär's ein Grund mißtrauisch zu werden.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote
> in <3C924BEB...@bigfoot.de>:
> # Jens Schweikhardt <use...@schweikhardt.net> wrote:
> #> Ja, anstatt portable Makefiles zu schreiben, sollte man lieber ein
> #> portables make benutzen.
> # Nein, sollte man nicht, wenn die Software allgemein beliebt werden
> # soll.
> Selbst dann, denn das "allgemein beliebt" werden hängt nicht davon ab,
> ob gmake benutzt wird, oder nicht, sondern ob die SW brauchbar ist.
Natürlich, aber die Brauchbarkeit von Software kann auch unter
Buildsystemen leiden, die in bestimmten Situationen unmäßig viel
Aufwand erfordern.
> arm-aout-binutils/Makefile:USE_GMAKE= yes
> arm-aout-gcc295/Makefile:USE_GMAKE= yes
Es ist mir neu, daß man dafür GNU make braucht. Ansonsten habe ich
nicht bestritten, daß es Programme gibt, die das brauchen. Ich habe
bestritten, daß das eine uneingeschränkt gute Idee ist. Ich würde
nicht einmal bestreiten, daß das manchmal Sinn macht; wenn das
Programm sowieso nur auf Systemen mit guter Softwarevorausstattung
übersetzt werden kann, ist es in der Tat nebensächlich. Aber in der
Generalität, mit der Du diese These offenbar vertrittst, verführt
sie Leute dazu, proprietäre Features zu verwenden, ohne auch nur
vorher nachgedacht zu haben.
> # Unportable Makefiles sind oft Anlaß genug, einen weiten Bogen
> # um das ganze Programm zu machen. Sie haben den Beigeschmack von »Mein
> # Programmierer hat einen beschränkten Horizont und ist egozentrisch«
> # und »Die Software selbst wird auch nicht recht portabel sein«.
> Wer solche Annahmen macht, verallgemeinert aus einem Einzelfall (welchem
> übrigens?)
Sorry, es ist zu lange her, daß ich ernsthaft auf UnixWare kompiliert
habe. UnixWare 2 fehlten IIRC reihenweise Funktionen, die im GNU- oder
BSD-Umfeld selbstverständlich sind, angefangen bei strcasecmp(). Da
war »benutzt GNU make« schon sehr oft ein Hinweis auf »das dicke Ende
kommt wohl noch«.
> und hat nicht verstanden, um was es geht.
Ich habe keinen zwingenden ursächlichen Zusammenhang behauptet. Ich
habe lediglich auf Koinzidenzen hingewiesen, und die wiederum sind
eigentlich auch nicht besonders überraschend.
> #> Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
> # Toll, der Maintainer betreibt Advocacy für sein Programm.
> gmake ist nicht das Programm von Smith; lies die erste Seite.
<http://www.gnu.org/manual/make-3.79.1/html_chapter/make_1.html#SEC1>
sagt: »Development since Version 3.76 has been handled by Paul D.
Smith«. Ich würde sagen, daß man sowas einen »Maintainer« nennt.
Gunnar
Jens Schweikhardt
in <3C97296A...@bigfoot.de>:
...
# Sorry, es ist zu lange her, daß ich ernsthaft auf UnixWare kompiliert
# habe. UnixWare 2 fehlten IIRC reihenweise Funktionen, die im GNU- oder
# BSD-Umfeld selbstverständlich sind, angefangen bei strcasecmp(). Da
# war »benutzt GNU make« schon sehr oft ein Hinweis auf »das dicke Ende
# kommt wohl noch«.
Das ist aber ein bischen dünn als Argument, zumal strcasecmp nichts mit
gmake zu tun hat, sondern mit der libc.
#> und hat nicht verstanden, um was es geht.
#
# Ich habe keinen zwingenden ursächlichen Zusammenhang behauptet. Ich
# habe lediglich auf Koinzidenzen hingewiesen, und die wiederum sind
# eigentlich auch nicht besonders überraschend.
Ich stelle diese Koinzidenz sehr in Frage. Natürlich gibt es
Programmierer, die gmake voraussetzen und merkwürdige Ansichten haben.
Aber es gibt darunter auch Leute, die Herr der Ringe lieben, Kaffe statt
Tee trinken, oder sonstwie abartig veranlagt sind :-) Solange Du nicht
nachweist, daß gmake-Voraussetzer *signifikant* Verschrobener sind,
solltest Du das nicht als Koinzidenz bezeichnen. Und immer dran denken,
eine Schwalbe macht noch keinen Frühling. Drei auch nicht.
#> #> Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
#> # Toll, der Maintainer betreibt Advocacy für sein Programm.
#> gmake ist nicht das Programm von Smith; lies die erste Seite.
#
# <http://www.gnu.org/manual/make-3.79.1/html_chapter/make_1.html#SEC1>
# sagt: »Development since Version 3.76 has been handled by Paul D.
# Smith«. Ich würde sagen, daß man sowas einen »Maintainer« nennt.
Das Maintainer ist ja richtig; ich störte mich an "seinem Programm".
Die meiste Arbeit haben wohl Roland McGrath und rms geleistet.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> wrote
> in <3C97296A...@bigfoot.de>:
> # Sorry, es ist zu lange her, daß ich ernsthaft auf UnixWare kompiliert
> # habe. UnixWare 2 fehlten IIRC reihenweise Funktionen, die im GNU- oder
> # BSD-Umfeld selbstverständlich sind, angefangen bei strcasecmp(). Da
> # war »benutzt GNU make« schon sehr oft ein Hinweis auf »das dicke Ende
> # kommt wohl noch«.
> Das ist aber ein bischen dünn als Argument, zumal strcasecmp nichts mit
> gmake zu tun hat, sondern mit der libc.
Natürlich hat es nichts mit gmake zu tun! Dinge wie /etc/vfstab
haben auch nichts mit gmake zu tun. Trotzdem ist die Verwendung
von gmake ein Anzeichen für Herkunft aus GNU- oder BSD-Umfeld,
was sich dann oft auch auf derartige andere Aspekte auswirkt.
> # Ich habe keinen zwingenden ursächlichen Zusammenhang behauptet. Ich
> # habe lediglich auf Koinzidenzen hingewiesen, und die wiederum sind
> # eigentlich auch nicht besonders überraschend.
> Ich stelle diese Koinzidenz sehr in Frage. Natürlich gibt es
> Programmierer, die gmake voraussetzen und merkwürdige Ansichten haben.
> Aber es gibt darunter auch Leute, die Herr der Ringe lieben, Kaffe statt
> Tee trinken, oder sonstwie abartig veranlagt sind :-) Solange Du nicht
> nachweist, daß gmake-Voraussetzer *signifikant* Verschrobener sind,
> solltest Du das nicht als Koinzidenz bezeichnen.
Mein Duden versteht unter »Koinzidenz« ein »Zusammentreffen von
Ereignissen«. Es genügt dafür vollkommen, daß diese Ereignisse
beobachtbar zusammentreffen. Ich habe sie beobachtet. Das reicht.
Ob das zufällig geschehen ist oder nicht, ist irrelevant.
> #> #> Paul's Rules for Makefiles, http://www.paulandlesley.org/gmake/rules.html
> #> # Toll, der Maintainer betreibt Advocacy für sein Programm.
> #> gmake ist nicht das Programm von Smith; lies die erste Seite.
> #
> # <http://www.gnu.org/manual/make-3.79.1/html_chapter/make_1.html#SEC1>
> # sagt: »Development since Version 3.76 has been handled by Paul D.
> # Smith«. Ich würde sagen, daß man sowas einen »Maintainer« nennt.
> Das Maintainer ist ja richtig; ich störte mich an "seinem Programm".
Okay, ich meinte damit »das Programm, das er maintaint«.
Gunnar
Jens Schweikhardt
in <3C9732B8...@bigfoot.de>:...
#> Ich stelle diese Koinzidenz sehr in Frage. Natürlich gibt es
#> Programmierer, die gmake voraussetzen und merkwürdige Ansichten haben.
#> Aber es gibt darunter auch Leute, die Herr der Ringe lieben, Kaffe statt
#> Tee trinken, oder sonstwie abartig veranlagt sind :-) Solange Du nicht
#> nachweist, daß gmake-Voraussetzer *signifikant* Verschrobener sind,
#> solltest Du das nicht als Koinzidenz bezeichnen.
#
# Mein Duden versteht unter »Koinzidenz« ein »Zusammentreffen von
# Ereignissen«. Es genügt dafür vollkommen, daß diese Ereignisse
# beobachtbar zusammentreffen. Ich habe sie beobachtet. Das reicht.
# Ob das zufällig geschehen ist oder nicht, ist irrelevant.
Es ist aber sehr wohl relevant, wenn man daraus Schlüsse zieht oder den
Eindruck erweckt, daß dieser Koinzidenz ein ursächlicher Zusammenhang
zugrundeläge. Aus dem schlichten "Zusammentreffen von Ereignissen" läßt
sich nämlich *nichts* folgern. Ich kenne nämlich auch Leute die POSIX
make benutzen und genauso schräge oder extreme Persönlichkeiten sind,
wie Du sie upthread beschrieben hast. Ich habe sie beobachtet. Also was
folgt daraus für den Zusammenhang zwischen make-Spielart und
Persönlichkeit? Nichts. Eben.
Gunnar Ritter
> # Mein Duden versteht unter »Koinzidenz« ein »Zusammentreffen von
> # Ereignissen«. Es genügt dafür vollkommen, daß diese Ereignisse
> # beobachtbar zusammentreffen. Ich habe sie beobachtet. Das reicht.
> # Ob das zufällig geschehen ist oder nicht, ist irrelevant.
>
> Es ist aber sehr wohl relevant, wenn man daraus Schlüsse zieht oder den
> Eindruck erweckt, daß dieser Koinzidenz ein ursächlicher Zusammenhang
> zugrundeläge.
Ich habe keine Schlüsse daraus gezogen. Ich habe eine Beobachtung
gemacht (die nun wirklich nicht abwegig ist) und Erklärungsansätze
für die beobachteten Fakten geboten. Wenn die Erklärungsansätze
falsch sein sollten, tangiert das die Beobachtung nicht.
Und ich spekuliere weiter: Natürlich trifft das nicht auf Dich zu
oder Leute wie Smith. Aber es kann sehr wohl für die Leute gelten,
die Eure Aufforderung zu proprietären GNU-Makefiles halbverstanden
akzeptieren. Das genau ist die Sache, um die es mir geht: Euer
Pauschaltip. Denn Pauschaltips sind fast immer schlecht, so auch
hier. Wir müssen nicht über Spekulationen am Rande diskutieren.
Die feinere Wahrheit ist: Wenn jemand über Wissen und Erfahrung
wie Ihr verfügt, kann er beurteilen, wann die Vorteile von GNU
make die Nachteile der proprietären Makefiles aufwiegen. Daß es
solche Fälle gibt, habe ich nicht bestritten. Aber Du verführst
hier Leute dazu, ihre Software unbedacht und unnötig einzuengen.
Das ist verkehrt. Es ist ähnlich verkehrt wie die Marotte, in
simplem und eigentlich portablem Shellcode $(...) statt `...`
einzusetzen, weil es irgendwie modern oder lesbarer erscheint.
Das tun die Leute genauso, weil ihnen jemand einen Pauschaltip
gegeben hat, und sie handeln sich vergleichbare Nachteile ein.
Warum gibst Du beim Thema make solche vordergründigen Tips? Das
tust Du doch sonst auch nicht.
Gunnar
Jens Schweikhardt
in <3C978436...@bigfoot.de>:
#
#> # Mein Duden versteht unter »Koinzidenz« ein »Zusammentreffen von
#> # Ereignissen«. Es genügt dafür vollkommen, daß diese Ereignisse
#> # beobachtbar zusammentreffen. Ich habe sie beobachtet. Das reicht.
#> # Ob das zufällig geschehen ist oder nicht, ist irrelevant.
#>
#> Es ist aber sehr wohl relevant, wenn man daraus Schlüsse zieht oder den
#> Eindruck erweckt, daß dieser Koinzidenz ein ursächlicher Zusammenhang
#> zugrundeläge.
#
# Ich habe keine Schlüsse daraus gezogen. Ich habe eine Beobachtung
# gemacht (die nun wirklich nicht abwegig ist)
Bisher hast Du nur eine Behauptung aufgestellt; ich habe schon danach
gefragt und eigentlich nur eine Nebelkerze bekommen: Wer konkret erfordert
gmake bei welchem Softwareprojekt und zeigt die von Dir aufgezählten
persönlichen Eigenheiten?
# und Erklärungsansätze
# für die beobachteten Fakten geboten. Wenn die Erklärungsansätze
# falsch sein sollten, tangiert das die Beobachtung nicht.
Dann würde ich es einfach bleiben lassen, solche beliebigen
Erklärungsansätze zu äußern. Ich beobachte auch, daß es heute regnet und
ich gmake benutze. Das ist Fakt. Ja und? Entweder mache ich hier eine
sinnleere Aussage, oder ich unterstelle einen Zusammenhang, oder warum
würde ich sonst eine solche Aussage machen?
...
# Die feinere Wahrheit ist: Wenn jemand über Wissen und Erfahrung
# wie Ihr verfügt, kann er beurteilen, wann die Vorteile von GNU
# make die Nachteile der proprietären Makefiles aufwiegen. Daß es
# solche Fälle gibt, habe ich nicht bestritten. Aber Du verführst
# hier Leute dazu, ihre Software unbedacht und unnötig einzuengen.
Das Gegenteil ist der Fall. Einzuengen hieße, in Makefiles auf sinnvolle
aber leider unportable Konstrukte zu verzichten, weil man auf POSIX make
eingeschränkt ist (z.B. include). Ich sage nicht, daß man immer gmake
benutzen soll -- wenn POSIX make ausreicht, dann ist es selbst-
verständlich vorzuziehen. Aber ab einer bestimmten kritischen Masse ist
der Verzicht auf rekursives make und der Einsatz von advanced
auto-dependency generation ein Gewinn, der die Kosten mehr als
wettmacht. Vielleicht macht das meine Position bezüglich make deutlicher
und wir können uns darauf einigen.
...
# Warum gibst Du beim Thema make solche vordergründigen Tips?
Wenn Du Dich damit auf den Link zu Pauls Rules for Makefiles beziehst:
Weil ich lange darüber nachgedacht und die Nützlichkeit am eigenen Leib
erfahren habe. Im übrigen finde ich diese Tips sehr *tiefgründig*.
In unserer Abteilung hat der PHB gmake aus gutem Grund (vor allem wegen
der heterogenen Plattformen und Vermeidung von Rekursion) zur Pflicht
gemacht.
# Das tust Du doch sonst auch nicht.
Stimmt, ich bemühe mich zu differenzieren (habe ich in diesem Posting
ansatzweise auch gemacht) aber manche Wahrheiten sind universell :-)
Gunnar Ritter
> Ich sage nicht, daß man immer gmake
> benutzen soll -- wenn POSIX make ausreicht, dann ist es selbst-
> verständlich vorzuziehen. Aber ab einer bestimmten kritischen Masse ist
> der Verzicht auf rekursives make und der Einsatz von advanced
> auto-dependency generation ein Gewinn, der die Kosten mehr als
> wettmacht. Vielleicht macht das meine Position bezüglich make deutlicher
> und wir können uns darauf einigen.
Sicher. Warum hast Du das nicht gleich geschrieben?
Gunnar
Jens Schweikhardt
in <3C98A858...@bigfoot.de>:#> Ich sage nicht, daß man immer gmake
#> benutzen soll -- wenn POSIX make ausreicht, dann ist es selbst-
#> verständlich vorzuziehen. Aber ab einer bestimmten kritischen Masse ist
#> der Verzicht auf rekursives make und der Einsatz von advanced
#> auto-dependency generation ein Gewinn, der die Kosten mehr als
#> wettmacht. Vielleicht macht das meine Position bezüglich make deutlicher
#> und wir können uns darauf einigen.
#
# Sicher. Warum hast Du das nicht gleich geschrieben?
Na weil sich die Diskussion anfänglich um ganz andere Aussagen drehte:
(nennt man topic drift)
Jens:
> Ja, anstatt portable Makefiles zu schreiben, sollte man lieber ein
> portables make benutzen.
Gunnar:
Nein, sollte man nicht, wenn die Software allgemein beliebt werden
soll ...
A propos vordergründige Verallgemeinerungen :-)
Gunnar Ritter
> #> Ich sage nicht, daß man immer gmake
> #> benutzen soll -- wenn POSIX make ausreicht, dann ist es selbst-
> #> verständlich vorzuziehen. Aber ab einer bestimmten kritischen Masse ist
> #> der Verzicht auf rekursives make und der Einsatz von advanced
> #> auto-dependency generation ein Gewinn, der die Kosten mehr als
> #> wettmacht. Vielleicht macht das meine Position bezüglich make deutlicher
> #> und wir können uns darauf einigen.
> # Sicher. Warum hast Du das nicht gleich geschrieben?
>
> Na weil sich die Diskussion anfänglich um ganz andere Aussagen drehte:
> (nennt man topic drift)
Ja, Du hast schon recht. Mein Versuch, das zu illustrieren, war
sicher auch nicht der geschickteste.
Gunnar
Felix von Leitner
> Es ist aber sehr wohl relevant, wenn man daraus Schlüsse zieht oder den
> Eindruck erweckt, daß dieser Koinzidenz ein ursächlicher Zusammenhang
> zugrundeläge.
Kannst du mal bitte sterben gehen? Woanders?
Nitpicker, die nichts beizutragen haben, sind überflüssiger als die bsh.
Danke.
Einweisung nach dag° erteilt.