Forum: Mikrocontroller und Digitale Elektronik Arduino: "Build-Optionen wurden verändert, alles wird neu gebaut."


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
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?

von G. H. (schufti)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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 vom Autor gelöscht.
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Das die Syntax von Makefiles hässlich ist brauchen wir hier nicht zu 
diskutieren. Ich denke, das ist allen klar, die damit arbeiten.

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
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
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Michael U. (amiga)


Bewertung
0 lesenswert
nicht lesenswert
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

von Ralf D. (doeblitz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
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
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.