Am Die, 19 Mär 2002 schrieb Andre:

Hallo Liste

Wenn ich beim Kompellieren mit "make" folgende Fehlermeldung bekomme: (`cimon' is up to date) dann darf ich doch davon ausgehen das ich neue Version von make brauche, oder? Wenn das der Fall ist wo bekomme ich dann eine neue Version her?

Nein, dann darfst Du davon ausgehen, daß Dein Projekt bereits fertig kompiliert wurde. Wenn Du unbedingt trotzdem kompilieren willst, probiere mal make clean und dann make Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

* Andre schrieb am 19.Mär.2002:

Wenn ich beim Kompellieren mit "make" folgende Fehlermeldung bekomme: (`cimon' is up to date) dann darf ich doch davon ausgehen das ich neue Version von make brauche, oder? Wenn das der Fall ist wo bekomme ich dann eine neue Version her?

Nein. Make hat nur sein Aufgabe gemacht. make ist ein Programm, daß je nach Abhängigkeiten andere Programme aufruft, und dabei möglichst Arbeit vermeiden soll. Beispiel. Du hast ein C-Sourcefiele: Programm.c und willst es übersetzen. Angenommen, Du befindest Dich in einem Verzeichniß, in dem es außer diesem Sourcefile keine weiteren Dateien gibt. Insbesondere kein Makefile und keinen Datei names Programm. Wenn Du dann make Programm sagst, so startet make den C-Compiler und das übersetzte Programm heißt dann Programm und befindet sich dann auch im Verzeichniß. Machst Du anschließend noch einmal make Programm, so bekomst Du die Meldung: `Programm' is up to date. Sonst macht make nichts, braucht es nicht, weil Programm schon up to date ist. Änderst Du aber was an Programm.c (braucht nur das Erstellungsdatum zu sein) dann wird make Programm wieder den C-Compiler aufrufen. Und genau das ist die Aufgabe von make. make hat noch eine ganze Menge Sachen mehr im Bauch, so weiß es auch, was es mit Pascal-, Fortran-, Assambler- und TeXProgrammen machen soll, auch mit yacc und lex kann es umgehen. Aber sehr bald ist make natürlich am Ende, es kann nicht wissen, daß Programm nicht nur von Programm.c sondern auch von Programm.h und vielleicht auch noch von IO.c, IO.h, comp.c, comp.h, misc.c abhängt, um das Make zu sagen, muß man ein Makefile schreiben. Es kann dann auch noch ein wenig komplizierter sein. So wird es sein, daß Programm von Programm.o, IO.o, comp.o und misc.o abhängt. Program.o hängt dann von Programm.c und Programm.h ab. IO.o hängt von IO.c und IO.h ab, comp.o von comp.c, comp.h und Programm.h und misc.o hängt von misc.c und Programm.h. So mal mein Beispiel. Wenn man nun Programm.h ändert und dann make Programm sagt, so wird zuerst Programm.o, comp.o und misc.o erzeugt, nicht aber IO.o, da es nicht von Programm.h abhängt und dann wird es zu Programm gebunden. Wie Du siehst versucht make so wenig wie möglich Arbeit zu machen. Wenn gar nichts mehr zu machen ist, dann sagt make halt, daß alles up to date ist. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

Hallo nochmal, Am Mittwoch, 20. März 2002 01:14 schrieb Bernd Brodesser:

* Bertram Scharpf schrieb am 19.Mär.2002:

...

Eine Möglichkeit gibt es, daß `make' nichts tut, obwohl es sollte. Die aber tritt bei Deinem Problem sehr wahrscheinlich _nicht_ auf. Änderungen in einer C-Header-Datei ("*.h") werden von `make' nicht erfaßt, es vergleicht nur das Datum der "*.c" mit den Kompilaten. Wurden die entsprechenden "*.c" nicht angefaßt, wird auch nicht kompiliert.

Aber nur dann, wenn man kein Makefile hat, aber dann gibt es bei nur make oder bei make clean eine Fehlermeldung, da make damit nichts anfangen kann.

Wenn es aber ein Makefile gibt, dann soll da gefälligst auch die Abhängigkeiten von *.h drin stehen.

Hab' ich nicht ganz verstanden; was meinst Du damit? Ich mußte mir extra ein Tool schreiben, das die Ausgabe von "cc ... -MM ..." einem Makefile beibringt. Da ein "*.h" /nie/ in ein "*.c" übersetzt wird, und da .c-Dateien ihre .h's wechseln können, ist `make' zwangsläufig überfordert, oder? Bertram -- Bertram Scharpf

On 20 Mar 2002 06:10:51 +0100, you wrote:

Der Standard-Ansatz dazu wäre, die Ausgabe von gcc -MM oder gcc -M in eine Datei umzuleiten

Aber dann bitte -MM, sonst werden auch System-Header wie /usr/include/stdio.h mit in die Abhängigkeiten genommen und dann passen die Abhängigkeiten u.U. nur auf dem einen System. Aber auch -MM hat einen Haken, denn dann werden nur mittles #include "header" eingebundene Header berücksichtig. [...]

[3] Ein Beispiel dafür: X11's makedepend (man makedepend).

Das ist aber bestimmt kein gutes Beispiel. Besser ist da schon gccmakedep, welches zu XFree86 gehört. Philipp

On 20 Mar 2002 07:35:58 +0100, you wrote:

Wenn Du die Deps on-the-fly generierst, wie es z.B. automake macht, willst Du normalerweise auch die Systemheader.

In dem Fall kann es egal sein :)

Wenn Du deps an Makefiles anhängen willst, dann hast Du recht.

Ich meinte Abhängigkeiten im Makefile.

Drum auch -M :)

Naja, ich halte nach wie vor handkodierte Abhängigkeiten im Makefile für die beste Lösung, denn ich müsste für mein Projekt ja wissen, was dazu gehört.

Ansonsten hast Du recht, wirklich gut ist makedepend nicht.

Das ist so wie mit imake, zu seiner Zeit eine gute Idee. Ich habe noch zu gut in Erinnerung, wie viel Arbeit es mich damals gekostet hat, Motif 1.2 an XFree86 anzupassen. Damals habe ich den Imake-Mechanismus hassen gelernt :) Philipp

* Ralf Corsepius schrieb am 20.Mär.2002:

Am Mit, 2002-03-20 um 04.53 schrieb Bertram Scharpf:

...

Hab' ich nicht ganz verstanden; was meinst Du damit?

Ich mußte mir extra ein Tool schreiben, das die Ausgabe von "cc ... -MM ..." einem Makefile beibringt. Davon mal abgesehen, dass "gcc -MM" (nicht cc, -MM ist gcc spezifisch) richtiger wäre, ist dem so. Nur, selbstverständlich gibt es derartige Tools schon.

Leute, was macht Ihr da? Es ergibt imho keinen Sinn mit Automake zu beginnen, wenn man das normale make noch nicht verstanden hat. Ist es nicht sinniger, erst mal klein anzufangen und ein Makefile von Hand zu schreiben? Ich meine natürlich eins für ein klitzekleines Projektchen, daß nur auf dem eigenen Rechner in ~/bin laufen soll? Wenn man das mal verstanden hat, dann kann man mit automake und Konsorten anfangen. Ist doch nicht normal, daß das erste Projekt, was ich schreibe gleich so mache, daß es auch auf verschiedene Maschienen unterschiedlichen Typs laufen können soll. Wenn ich ein Makefile habe, und foo.o von foo.c, foo.h und bar.h abhängt, so reicht eine Zeile im Makefile, die lautet: foo.o: foo.c, foo.h, bar.h das war es. Die kann man mit Hand eingeben. Natürlich nicht, wenn man ein Makefile automatisch generiert hat, (können schon, aber nicht sollen) aber das sollte man imho gleich am Anfang noch nicht machen. Selbstredend, daß dies kein Vorgehen für größere Projekte ist, aber wenn ich eine Schreinerlehre mache, dann fange ich auch nicht an Tische oder Schränke zu zimmern, sonder erst mal einen Klotz glatthobeln, den man anschließend für die Nachkommen aufbewahrt oder wegschmeißt. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11