Ich arbeite derzeit intensiv an einem Projekt mit dem Wemos D1 Mini - und zwar mal am Macbook, mal am Schreibtisch-iMac. Auf beiden sind das gleiche OSX 10.13 und die gleiche IDE-Version 1.85 installiert. Während am Macbook die oben genannte Meldung vor dem Compilieren nur bei wirklich fundamentalen Änderungen im Sourcecode oder den Optionen erscheint, habe ich das am iMac prinzipiell bei jedem Compilerlauf. Selbst dann - hab' ich ausprobiert - wenn ich nur am Blink-Beispiel die delay-Werte ändere. Wo könnte die Ursache liegen?
das Problem hatte ich am PC ab IDE >1.6.5. bei esp arduino core >2.3 immer wieder mal, hängt irgendwie mit der boards.txt zusammen. Mit der IDE 1.8.6 (nightly) ist das Problem mit der Einstellung "agressive caching core" gelöst.
:
Bearbeitet durch User
Bin auch davon betroffen. Ich wünschte, die Arduino IDE würde einfach das gute alte "make" verwenden, dann hätten wir solche Probleme nicht.
Stefanus F. schrieb: > Bin auch davon betroffen. Ich wünschte, die Arduino IDE würde einfach > das gute alte "make" verwenden, dann hätten wir solche Probleme nicht. Auch da löst traditionell eine Änderung am Makefile (z.B. wegen Veränderung der Compiler-Flags) einen kompletten Rebuild aus. Wenn die IDE also (unnötigerweise) das Makefile neu schreibt, dann bringt das keinerlei Vorteil.
Beitrag #5516079 wurde von einem Moderator gelöscht.
Ralf D. schrieb: > Auch da löst traditionell eine Änderung am Makefile (z.B. wegen > Veränderung der Compiler-Flags) einen kompletten Rebuild aus. Nein, das muss man explizit erzwingen. Ansonsten gelten nur die Zeitstempel von Quell- und Zieldateien.
:
Bearbeitet durch User
Bernd K. schrieb: > Ralf D. schrieb: >> Auch da löst traditionell eine Änderung am Makefile (z.B. wegen >> Veränderung der Compiler-Flags) einen kompletten Rebuild aus. > > Nein, das muss man explizit erzwingen. Ansonsten gelten nur die > Zeitstempel von Quell- und Zieldateien. Alles im Makefile ist erzwungen - man schreibt es schließlich selbst hin. ;-) Und traditionell hat man da eigentlich immer eine Abhängigkeit aller Ziele vom Makefile selbst mit abgegeben (d.h. so kenne ich das aus vielen Projekten, YMMV) - eben weil die Änderung des Makefiles bedeutet, das man sich nicht darauf verlassen kann, dass alles so gebaut wurde wie es nach der Änderung im Makefile drin steht.
Ralf D. schrieb: > Und traditionell hat man da eigentlich immer eine Abhängigkeit aller > Ziele vom Makefile selbst mit abgegeben Ja das sowieso. Und jetzt kommt Stufe 2: make all make all DEBUG=1 Wenn man Variablen entgegen nimmt die die compiler-flags ändern und das auch noch automatisch erkennen will muss man noch tiefer in die Trickkiste greifen und richtig hartes voodoo anwenden, von alleine macht es das nicht:
1 | ALLFLAGS=$(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS) |
2 | .PHONY: force |
3 | $(BUILDDIR)compiler_flags: force |
4 | echo '$(ALLFLAGS)' | cmp -s - $@ || echo '$(ALLFLAGS)' > $@ |
5 | $(OBJS): $(BUILDDIR)compiler_flags |
Das die Syntax von Makefiles hässlich ist brauchen wir hier nicht zu diskutieren. Ich denke, das ist allen klar, die damit arbeiten.
Stefanus F. schrieb: > Das die Syntax von Makefiles hässlich ist brauchen wir hier nicht zu > diskutieren. Ich denke, das ist allen klar, die damit arbeiten. Es ging eher darum, dass bei Änderungen der Buildoptionen ein kompletter Rebuild fällig ist, egal ob man make (und dafür wurde das angezweifelt), die Arduino-IDE oder irgendwas anderes benutzt.
Ralf D. schrieb: > Es ging eher darum, dass bei Änderungen der Buildoptionen ein kompletter > Rebuild fällig ist, egal ob man make (und dafür wurde das angezweifelt), > die Arduino-IDE oder irgendwas anderes benutzt. Nee, sorry, es ging darum, dass auf meinem Macbook der complette Build - wie eigentlich logisch - nur bei grundsätzlichen Änderungen notwendig wird, während das auf meinem iMac prinzipiel immer passiert (beim gleichen Projekt). Wo könnte die Ursache stecken bzw. wie kann ich das Verhalten der IDE auf meinem iMac korrigieren? Die Option "... more aggressive" im Setup der IDE hat darauf jedenfalls keinen Einfluss.
:
Bearbeitet durch User
Mein Glaskugel sagt: Serverzeit und lokale Zeit/Datum unterscheiden sich. Wenn die *.cpp/*.ino jünger als die *.a dann wird kompiliert. Also sind die Dateien auf 2 Rechner verteilt und die Uhren laufen nicht synchron. ohne Gewähr
Arduino Fanboy D. schrieb: > Mein Glaskugel sagt: > Serverzeit und lokale Zeit/Datum unterscheiden sich. > > Wenn die *.cpp/*.ino jünger als die *.a dann wird kompiliert. > Also sind die Dateien auf 2 Rechner verteilt und die Uhren laufen nicht > synchron. > > ohne Gewähr Nö. Beide Rechner laufen mit Internet-Time-Sync über de.pool.ntp.org. Das Projekt steckt komplett in einem Ordner, der bei Bedarf zwischen Macbook und iMac hin- und her kopiert wird. Beim ersten Compilerlauf nach der Kopie würde ich das am iMac ja noch verstehen, aber der will immer ... wie oben beschrieben, selbst wenn man nur eine Leerzeile in die Source einfügt ...
:
Bearbeitet durch User
Frank E. schrieb: > Das Projekt steckt komplett in einem Ordner, der bei Bedarf zwischen > Macbook und iMac hin- und her kopiert wird. Das ist, so absolut, nicht wahr. Die kompilierten Dateien finden sich in einem Temp Ordner. Und da hat, in der Regel, jeder Rechner seinen Eigenen. Es dreht sich ja gerade um die Dateien im Temp Ordner. Der Datums/Zeit Vergleich schlägt fehl. Warum auch immer.... (da reichen meine MAC OS Kenntnisse nicht aus)
Hallo, IDE als portable installieren sollte eigentlich auch am MAC gehen und dann bleibt wirklich alles im Ordner der IDE. Wenn man einen halbwegs schnelle USB-Stick o.ä. hat, kann man die IDE auch gleich da drauf lassen und von dort starten. Gruß aus Berlin Michael
Frank E. schrieb: > Ralf D. schrieb: > >> Es ging eher darum, dass bei Änderungen der Buildoptionen ein kompletter >> Rebuild fällig ist, egal ob man make (und dafür wurde das angezweifelt), >> die Arduino-IDE oder irgendwas anderes benutzt. > > Nee, sorry, es ging darum, dass auf meinem Macbook der complette Build - > wie eigentlich logisch - nur bei grundsätzlichen Änderungen notwendig > wird, während das auf meinem iMac prinzipiel immer passiert (beim > gleichen Projekt). Jein, du meintest dann noch, dass dir ein make lieber wäre und ich merkte an, dass auch dann bei Änderung des makefiles das gleich passieren würde. ;-) Egal, du hast ja kein make in der IDE und es würde dir auch nicht helfen (aber so ärgerst du dich vielleicht nicht ganz so doll). > Wo könnte die Ursache stecken bzw. wie kann ich das Verhalten der IDE > auf meinem iMac korrigieren? Passiert das jedes Mal oder nur nach dem Kopieren? Haben beide Systeme den gleichen Filesystem-Typ (da gibt es ja unterschiedliche Zeitauflösungen für die Timestamps) und benutzen beide die gleiche Zeitzone (bzw. UTC auf Systemebene) ? So etwas hat mich mal beim Austausch mit DOS-Filesystemen genervt.
Ralf D. schrieb: > Und traditionell hat man da eigentlich immer eine Abhängigkeit aller > Ziele vom Makefile selbst mit abgegeben (d.h. so kenne ich das aus > vielen Projekten, YMMV) - eben weil die Änderung des Makefiles bedeutet, > das man sich nicht darauf verlassen kann, dass alles so gebaut wurde wie > es nach der Änderung im Makefile drin steht. Traditionell kenne ich die Variante, dass bei einer Änderung am Buildsystem (egal welcher) erstmal ein "make clean" notwendig ist.
S. R. schrieb: > Traditionell kenne ich die Variante, dass bei einer Änderung am > Buildsystem (egal welcher) erstmal ein "make clean" notwendig ist. Ja. make clean ist der Dampfhammer. "Notwendig" wie Du es formulierst ist er aber nicht immer sofern es noch möglich ist den Überblick darüber zu haben wo sich die Änderung überall auswirken wird und wo nicht. > egal welcher manche Arten von Änderungen kann man automatisch erkennen lassen und automatisch immer richtig behandeln lassen.
:
Bearbeitet durch User
Vollkommen richtig, allerdings in den meisten make-basierten Buildsystemen (auch meinen eigenen) eben nicht so implementiert. Was auch einer der Grundgedanken hinter ninja (dem derzeitigen Buildsystem hinter Android) ist. Nur mit dem Unterschied, dass man sinnvoll Makefiles per Hand schreiben kann, Ninja-Files nicht. Dafür braucht man ein Meta-Buildsystem wie CMake (grausam).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.