Hallo, gibt es etwas, mit dem ich zwischen verschiedenen Versionen und Builds des GCCs wechseln kann und benötigte (noch fehlende) Versionen einfach installieren kann? Also in etwa das, was RVM für Ruby ist. Auf der Suche nach "GCC Version Manager" habe ich einige Ansätze gefunden, die sind aber scheinbare alle in der Pilot-Phase stecken geblieben. Wie stellt Ihr sicher, dass die Tools (binaries) zum Bau von Firmware auch noch nach Jahren auffindbar sind? Einfach mit ins Repo kippen? mfg Torsten
Torsten Robitzki schrieb: > Wie stellt Ihr sicher, dass die Tools (binaries) zum Bau von Firmware > auch noch nach Jahren auffindbar sind? Einfach mit ins Repo kippen? 1.) Dokumentieren, mit welchem Compiler und welcher Version die Software gebaut wurde. 2.) Dieses Dokument muss natürlich mit in ein Backup, welches die Jahre überdauert. 3.) Binaries der verwendeten Tools ebenfalls Archivieren. Ins Code Repository gehören sie eher nicht rein, eben weil kein Code, sondern in eine Art Tools-Datenbank. Die wiederum archiviert wird.
Hi Mark, ja an so etwas hatte ich auch schon gedacht. Die Repositories werden eh archiviert. Ein eigenes Repetitory für Tools erscheint auch sinnvoll, wenn man daran denkt, dass sich mehrere Projekte durchaus die gleichen Tools teilen können. In ein Projekt könnte man zusätzlich noch einen build step integrieren, der prüft, dass die richtigen Versionen der Werkzeuge verwendet werden. Das wäre dann evtl. auch schon die Dokumentation. Schönen Dank und freundliche Grüße, Torsten
Torsten Robitzki schrieb: > Hallo, > gibt es etwas, mit dem ich zwischen verschiedenen Versionen und Builds > des GCCs wechseln kann und benötigte (noch fehlende) Versionen einfach > installieren kann? Neuere gcc-Versionen - zumindest, wenn sie "standardmäßig" gebaut sind - können beliebig oft nebeneinander installiert werden, sie halten die Versionsnummer im Namen und "gcc" ist nur ein symbolischer Link dahin (meist auf die neueste Version). Will man eine bestimmte Version nutzen, ruft man halt (z.B.) statt "gcc" "gcc-4.9.1" auf. Das läßt sich im Makefile prima automatisieren.
Markus F. schrieb: > Will man eine bestimmte Version nutzen, ruft man halt (z.B.) statt "gcc" > "gcc-4.9.1" auf. Das läßt sich im Makefile prima automatisieren. Ok, das würde auf jeden Fall dabei helfen, dass sich die Firmware nur mit der "richtigen" Version bauen lässt. Danke für den Hinweis.
Mark Brandis schrieb: > Torsten Robitzki schrieb: >> Wie stellt Ihr sicher, dass die Tools (binaries) zum Bau von Firmware >> auch noch nach Jahren auffindbar sind? Einfach mit ins Repo kippen? [...] > 3.) Binaries der verwendeten Tools ebenfalls Archivieren. Ins Code > Repository gehören sie eher nicht rein, eben weil kein Code, sondern in > eine Art Tools-Datenbank. Die wiederum archiviert wird. Wobei noch zu bedenken wäre dass alte Tools auf aktuellen Betriebssystemen nicht notwendigerweise laufen (OK, betrifft GCC wohl eher nicht). Dann müsste man z.B. komplette virtuelle Maschinen archivieren, ist sowieso schick weil es den Setup-Aufwand minimiert. Dann muss man natürlich beten dass die VM nach n Jahren noch geht. Und beim Build nicht etwa auf lange verschwundene Internet-Ressourcen (XML-Schemas z.B.) zugreift. Usw. usf. Über lange Zeiträume gesehen ist das alles ein veritabler Alptraum...
Jasch schrieb: > Über lange Zeiträume gesehen ist das alles ein veritabler Alptraum... Da hast Du Recht. Da würde ich aber das Risiko eingehen, dass im Notfall, der Quellcode noch mal an eine neuere Compiler-Version angepasst werden müsste. C und C++ sind standartisierte Sprachen und da sollten es ja maximal ein paar Kleinigkeiten sein ;-)
Jasch schrieb: > Wobei noch zu bedenken wäre dass alte Tools auf aktuellen > Betriebssystemen nicht notwendigerweise laufen (OK, betrifft GCC wohl > eher nicht). was sogar bei Linux ein größere Problem als bei Windows ist. Man bekommt bei Linux einfach alte Pakete nicht mehr sinnvoll installiert, wegen dem Abhängigkeiten. Da müsste man sich alles selber compileren. unter Windows kann man auch 10Jahre alte GCC einfach zum laufen bringen. Wir verwenden den MSVC und diese liegt in jeder genutzten Version in einem Share, im Projekt ist dann einfach hinterlegt welcher Version vom Compiler zu genutzt werden soll.
Jasch schrieb: > Über lange Zeiträume gesehen ist das alles ein veritabler Alptraum... Es ist eher eine Kostenfrage. Was zu tun ist ist klar. Notfalls lagert man Hardware mit ein. Wenn es sein muss in irgendeinem unterirdischen ehemaligen Bunker aus dem kalten Krieg. Eine andere Strategie ist das regelmäßige Vorwärtsportieren. Ohne das es konkrete Änderungswünsche am Code gibt, entstaubt man ihn regelmäßig. D.h. man holt eine von mehreren Kopien aus dem Archiv vom Datenträger, portiert ihn mit den neusten Tools, nimmt, wenn nötig, die neusten Bibliotheksversionen, baut einen Testaufbau neu auf, testet, und lagert dann alles wieder ein, eventuell auf einem anderen, moderneren Typ von Datenträgern. Sollte man irgendwann wirklich wieder an den Code müssen hat man dadurch eine bessere Ausgangsbasis. Statt 10 Jahre (== Neuschreiben) muss man vielleicht nur zwei Jahre aufholen. Einlagern, Vorwärtsportieren usw. sind so eine Art Versicherungsprämie die man zahlt. Eventuell braucht man sie nie, dann ist das Geld verschwendete. BWLer sind daher meist strickt dagegen. Gesetzliche Vorschriften helfen bei der Argumentation :-)
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.