C/C++, vorkompilierte Dateien?
-
Also bei offiziellen Builds, die dann auch ausgeliefert werden, mache ich vorher auch ein clean ( also mein Buildscript macht das ), eben wegen der bereits beschriebenen möglichen Verwirrungen. Sicher ist sicher.
Während der Entwicklung mache ich seltener clean, weil eben ein kompletter Rebuild zu lang dauert.
Von welchen Build-Laufzeiten reden wir denn hier?
Du klingst jetzt nicht unbedingt so, als hättest du selber Software-Entwicklungs-Hintergrund. Warum willst du deinem Entwickler reinreden?
-
Hallo zusammen
Vielen Dank für die hoch kompetenten Feedbacks!!
Mit freundlichen Grüssen,
Jan
-
@wob sagte in C/C++, vorkompilierte Dateien?:
Schreibt ihr denn das Makefile selber oder nutzt ihr einen Generator wie cmake? Als ich noch das Makefile von Hand geschrieben habe, musste ich auch oft make clean laufen lassen, weil man einfach zu leicht vergessen kann, das Makefile mit anzupassen.
Teils teils. Vergessen, das Makefile anzupassen ist genau der Grund, wieso man es nicht selber schreiben sollte. Andererseits bin ich mit Makefiles so viel besser als mit den Makefilegeneratoren, dass die Benutzung einer Autotoolchain ein für mich nicht unerheblicher Mehraufwand ist. Daher wäge ich halt ab, was ich für den insgesamt kleineren Aufwand halte: Makefile selber schreiben, bei Projektanderungen nachziehen, und abundzu frustrierende Fehler haben, weil ich dies vergessen habe; gegenüber dem Mehraufwand mit einer Autogenerierung, wo größere Änderungen auch nicht trivial sind (kleine aber schon), und wo ich tendenziell mehr Fehler mache.
Das Wichtigste aber zum Schluss: Wenn ich auf Portabilität achten muss, es also nicht nur mein Privatspaß ist, führt an einer Autogenerierung wenig vorbei.
-
Ich kämpfe auch eher gegen CMake als dass ich mit CMake arbeite.
Da ich mich aber auch mit Makefiles nicht sonderlich auskenne und CMake mir Out-of-Source-Builds bietet und auch z.B. automatisch mit CPack ein .deb bauen kann, beiße ich dann doch in den Apfel mit negativem pH-Wert und stümpere mir eine CMakeLists.txt zusammen
-
Irgendwie bekomme ich keine Mails bei Antworten, dies obwohl "Beobachtet" ausgewählt wurde. Oder hat dies nix mit Mails zu tun...? Vielen Dank für die Feedbacks.
Mit freundlichen Grüssen,
Jan
-
@jmar83 sagte in C/C++, vorkompilierte Dateien?:
Irgendwie bekomme ich keine Mails bei Antworten, dies obwohl "Beobachtet" ausgewählt wurde. Oder hat dies nix mit Mails zu tun...? Vielen Dank für die Feedbacks.
Ob rechts auf dein Icon klicken, auf Einstellungen gehen und dort kannst du einstellen, bei welchen Benachrichtigungen du eine E-Mail bekommst. Standardmässig werden keine E-Mails verschickt.
-
Vielen Dank, das scheint wohl geklappt zu haben. (Bei der nächsten Antwort werde ich sehen, ob dann ein Mail reinkommt...)
Zurück zum Thema:
- Mit der originalen Geschwindigkeit des Raspiberry Pi 3B+ (=4x 1.4Ghz) ging das Kompilieren ca. 1 Std. und 10 Min.
- Nachdem Übertakten auf 4x 1.55Ghz meldete der Compiler mittendrin einen "segfault"...
- Nach dem Anpassen der Übertaktung von 4x 1.55GHz auf 4x 1.5Ghz war der "segfault" weg und es dauerte noch ca. 1 Stunde
- Nach der Installation von "ccache" und bei der ersten Kompilation ging's weniger als 1 Stunde. (Schon bei der ersten Kompilation mit "ccache" gab's wohl irgendwelche "Überschneidungen" - es werden insgesamt 7 Sachen kompiliert, 3 Libraries (zuerst) und dann anschliessend noch 4 ausführbare Anwendungen)
- Nach der 2. Kompilation mit "ccache" dauerte es noch ca. 5.5 Minuten!!!!!
-> Die Tipps zum Übertakten habe ich von hier: https://miguelangelantolin.com/raspberry-pi-3-b-overclocking/ (-> Einfach "1550" mit "1500" ersetzen!!)
-> "ccache" aufzusetzen war auch total easy... so wie es hier beschrieben wird, funktioniert's auch bei Raspbian Stretch (aktuelle Version): https://askubuntu.com/questions/470545/how-do-i-set-up-ccache
"Du klingst jetzt nicht unbedingt so, als hättest du selber Software-Entwicklungs-Hintergrund. Warum willst du deinem Entwickler reinreden?"
...bin auch Entwickler, zumindest so halbwegs (nebenbei Projektleitung und auch noch zuständig für die interne IT, quasi "Junge für alles" halt..;-)), allerdings komme ich eher aus der Richtung Java, PHP & .NET (Der Server-Teil von Webapps halt, GUI-Sachen sind jedoch weniger "meins") wie auch SQL.
Nebenbei kenne ich mich noch mit Shell-/Bashskripts unter Linux aus, und das aktuelle Thema ist ein Skript, welches von "git pull" übers Kompilieren (C/C++-Hintergrunddienste) zum Packen (.deb-Datei) hin bis zur Verteilung auf's APT-Repo alles macht. (das Paket "reprepro" kann ich dafür wärmstens empfehlen -> https://blog.packagecloud.io/eng/2017/03/23/create-debian-repository-reprepro/ )
Deshalb war ich auch mit der Kompilierungszeit der C/C++-Sachen beschäftigt. Wir haben uns zuerst überlegt, meine Skripte konfigurierbar zu machen (also so dass nicht immer alle 7 "targets" kompiliert werden müssen, etwa über Parameter), nun scheint der ganze Prozess max. 20 Minuten zu dauern - also kein Problem, um immer alles zu kompilieren!!
Mit freundlichen Grüssen,
Jan
-
Heißer Tipp: Compilier nicht auf einem Raspberry Pi, sondern für einen Raspberry Pi. Auf einem normalen Desktoprechner sollte das um ein Vielfaches schneller gehen. Crosscompiling (wie man das nennt) ist zwar nicht ganz einfach und wird bei den ersten Versuchen bestimmt oft schief gehen, aber für so eine beliebte Plattform wirst du bestimmt viele Anleitungen oder gar fertige Werkzeuge finden. Ich brauchte bei Google bloß 'cros' einzugeben und es wurde mir schon 'cross compiling raspberry pi' vorgeschlagen. Ich bin also wohl nicht der Erste mit dieser Suchanfrage
-
Vielen Dank für den Tipp. Daran habe ich auch schon gedacht, aber die ganze Konfiguration hat mich vom Thema abgehalten.
Na ja, vielleicht ist es ja doch nicht soooooo schwierig, werde es wohl bei der nächsten Gelegenheit ausprobieren. (Aber aktuell hab ich der Belegschaft und dem Chef schon mitgeteilt, dass mein Projekt (im Grossen und Ganzen) fertig ist und es nun genutzt werden kann..)
P.S.: Nun klappt's auch mit der Mail-Benachrichtigung wenn jemand im Forum hier antwortet - ebenfalls vielen Dank!
-
@jmar83 sagte in C/C++, vorkompilierte Dateien?:
- Nachdem Übertakten auf 4x 1.55Ghz meldete der Compiler mittendrin einen "segfault"...
- Nach dem Anpassen der Übertaktung von 4x 1.55GHz auf 4x 1.5Ghz war der "segfault" weg und es dauerte noch ca. 1 Stunde
- Nach der 2. Kompilation mit "ccache" dauerte es noch ca. 5.5 Minuten!!!!!
Ich würde die Übertaktung wieder rückgängig machen. Nicht jeder Fehler den die CPU bei zu hohem Takt macht muss in nem SIGSEGV enden. Wenns blöd hergeht erzeugt das Ding ein Programm das auch anscheinend das macht was es soll, aber dann irgendwo doch nicht richtig funktioniert. Nachdem der Gewinn durch Übertaktung sowieso so gering ist, ... wäre es mir das Risiko nicht wert.
-
"Ich würde die Übertaktung wieder rückgängig machen. Nicht jeder Fehler den die CPU bei zu hohem Takt macht muss in nem SIGSEGV enden."
Bin bin es eigentlich gewöhnt, dass dabei der Rechner einfriert!
(Das Problem mit diesem Fehler hängt aber 100% mit der Übertaktung zusammen, vorher ging's x mal ständig gut...)"Nachdem der Gewinn durch Übertaktung sowieso so gering ist, ... wäre es mir das Risiko nicht wert."
Volle Zustimmung, jetzt mit dem "ccache" geht's ja ohnehin ab wie die Post!
-
@jmar83 sagte in C/C++, vorkompilierte Dateien?:
"Ich würde die Übertaktung wieder rückgängig machen. Nicht jeder Fehler den die CPU bei zu hohem Takt macht muss in nem SIGSEGV enden."
Bin bin es eigentlich gewöhnt, dass dabei der Rechner einfriert!
(Das Problem mit diesem Fehler hängt aber 100% mit der Übertaktung zusammen, vorher ging's x mal ständig gut...)Hi! Ich bin hier zwar etwas spät dran, aber das ist wohl ein Problem das sich ohnehin nicht so schnell in Luft auflöst.
Scheinbar wurde hier im Thread noch nicht erwähnt, dass sich
makemit der Option-j<N>auch parallel betreiben lässt. Das würde ich zuerst versuchen, bevor du solche abenteuerlichen Sachen wie "CPU übertakten" machst. Versuch es erstmal mitmake -j8für eine 4-Kern-CPU mit Hyperthreading.Es gibt kaum etwas, das so gut von massiver Parallelisierung profitiert wie die meisten Build-Prozesse. Abhängigkeitsprobleme in den Makefiles sind hier allerdings kontraproduktiv und können den Parallel-Build auch unmöglich machen. Einen Versuch sollte es dennoch wert sein.
-
Hallo Finnegan
Danke für Deinen Beitrag!
Da das Raspi (3B+) zwar 4 Kerne hat jedoch kein Hyper-Threading (gibt's doch nur bei x86/x64/PC-kompatiblen CPUs?) habe ich mit der Option "-j4" kompiliert. Scheint zu klappen.
(Hyper-Threading macht auf einen phys. Kern 2 virtuelle, so habe ich es zumindest im Windows-Gerätemanager beobachtet, bin mir aber noch 100% sicher ob meine Vorstellung stimmt?)
Ob ein Zuwachs an Geschwindigkeit gegeben ist, sehen ich am Schluss des Build-Prozess. (Zeitdifferenz messen im Shell-Skript)
Aktuell bin ich immer noch beim Raspi geblieben (statt cross-compile auf einem PC), da mir "ccache" die ganze Sache extrem beschleunigt hat.
Ich schreibe dann noch mal einen Beitrag wenn es fertig ist!
-
Super, hat geklappt, Ziel erreicht - vielen vielen Dank!!
Nun bin ich bei 17 Minuten statt bei 19-20 Minuten wie vorher.
Wobei eh ein grosser Teil der Zeit gebraucht wird um das .deb-File zu packen (dpkg -b ...), aber dazu habe ich gelesen dass "dpkg-deb" (statt "dpkg") es zulassen würde die Kompressionsmethode sowie -stufe anzupassen. Na ja, das Packen (build) und das Entpacken (install) wäre damit schneller, die Datei allerdings grösser zum downloaden. Man muss halb abwägen...
Und, nur so nebenbei: Die Option "--force-unsafe" bei "dpkg" scheint auch nicht viel zu bringen, ist evtl. nur zum Installieren geeignet statt zum Builden per "dpkg"... Warnung (in Kombination mit dem Parameter "-b") bekomme ich aber keine...
-
@jmar83 Kann es sein dass du ein tipp-fehler hast? Denn --force-unsafe gibt es nicht als parameter für dpkg. Meintest du eher --force-unsafe-io?
-
Oh ja, "--force-unsafe-io" ist korrekt, so ist es auch in meinem Skript hinterlegt.
-
@jmar83 sagte in C/C++, vorkompilierte Dateien?:
Kompressionsmethode
Probier mal aus wie gross der Unterschied ist (Zeit und Filegrösse). Oft bringt das Runterschalten der Kompressionsstuft viel Zeit, kostet aber gleichzeitig nicht viel. Und das wäre vielleicht auch was wo man während der Entwicklungsphase andere Einstellungen verwenden könnte wie dann für's Bauen des Release.
-
Werde die Sache mit der Kompression bei Gelegenheit testen, aktuell war ich gerade wieder mal mit einem Problem beschäftigt welches mich irritiert hat: Nach einer Änderung der C/C++-Quelltexte war der Computer (Raspi 3B+ inkl. "ccache") x Minuten bei 90%, kurze Zeit später ist das System komplett abgestürzt. Keine SSH-Verbindung mehr etc. Auch das Einloggen am lok. Rechner ist gescheitert.
Anschliessend habe ich die Werte für das Swapfile angepasst in /etc/dphys-swapfile:
CONF_SWAPSIZE=4096
CONF_MAXSWAP=8192...damit hat es dann geklappt. (Während dessen ständig überprüft mit "free -m") Sicher genug und ausreichend virt. Speicher!
-
@hustbaer: Zur Kompression: Also mit "dpkg-deb --nocheck -Zgzip -z2 -Srle -b ./xyz;" wird der Pack-Vorgang um ein x-faches schneller (in etwa: weniger als eine Minute statt ein paar im Vergleich zu vorher) Die .deb-Datei ist rund 3x so gross wie vorher (150MB statt wenig grösser als 50)
Natürlich könnte man noch lange mit den Einstellungen spielen, am schnellsten wäre wohl unkomprimiert, aber das wird dann doch irgendwie zu gross... also lasse ich den Befehl mal so, wie er ist.
Und das .gzip-Format hat den Vorteil, dass es sich wohl problemlos (werde es morgen anschauen) mit den gängigen Windows-Packern (7Zip, WinZip, WinRAR) entpacken lässt - im Ggs. zu dem dpkg-eigenen Format ("xz" steht unter http://man7.org/linux/man-pages/man1/dpkg-deb.1.html, "ar" musste ich bei einer Java-Anwendung mit den "Apache Commons Compress" auswählen... hmmm...??) Wobei ich aktuell unter Windows 7Zip klar bevorzuge.
Es loht sich schon, die Vorgabewerte zu ändern falls es zu langsam geht - definitiv. Insbesondere während den Entwickeln (und Testen) ist dies sicher von Vorteil.
-
...und noch was:
"-> Die Tipps zum Übertakten habe ich von hier: https://miguelangelantolin.com/raspberry-pi-3-b-overclocking/ (-> Einfach "1550" mit "1500" ersetzen!!)"
Wenn schon übertakten, dann wenigstens den GPU-Speicher auf das Minimum (?) von 16MB setzen, damit ein wenig mehr zum Kompilieren übrig bleibt!
(Siehe vorletzter Post)
Und mit den Übertakten habt ihr recht, damit muss man vorsichtig sein... habe das Raspi (im Gehäuse, aber ohne Deckel) nun in den Serverraum gestellt wo es ein wenig wärmer ist. Und schon macht das Ding Stress. (Exakt gleiches Netzteil & USB-Stromkabel, daran kann es schon mal nicht liegen...)
