Am 24.02.2015 um 16:55 schrieb Richard Weickelt: > >> I'll have a look at the TI/RH binary release later. > > cool. Glaube aber kaum, dass lto soo viel bringt. avr-gcc 4.8.1 erzeugt mit > lto größere Binaries, aber da soll es wohl einen Bug beim inlinen geben. In > meiner VM hat übrigens das "binary release" von TI nicht funktioniert, weil > es angeblich die (x86) libstdc++ nicht finden konnte. Glücklicherweise > patchen sie dank Redhat nicht vor jedem Release noch eigene Änderungen > hinein wie das bei Atmel traurigerweise immer wieder vorkommt, sondern > pushen alles upstream. >
Hauptsache die garbage collection (functions/sections) funktioniert wenigstens noch. Dass die Binaries von TI nur 32bit sind, ist aber ärgerlich. Die meisten Entwickler sollten ja mittlerweile 64bit Systeme haben. Naja ich probier's später aus. > Lass uns doch evtuelle weitere Diskussionen auf die Mailingliste verlegen > [...] ... ist hiermit geschehen ;) > > Danke auch für Deinen Einsatz mit sonar cube. Sieht schon mal toll aus und > ist sehr hilfreich wenn man auf einen Blick sieht, ob und was sich mit der > Zeit verändert. > [ Für die Liste: www.sonarqube.org - das habe ich für Reflex aufgesetzt, aber noch nicht fertig konfiguriert. Zugang vorerst auf Anfrage ;) ] Das "was sich verändert" ist eine Metrik, an denen der SST Lehrstuhl[1] intensiv arbeitet. Die können filtern, an welchen Code-Teilen viel rumgebaut wird (und an welche sich keiner mehr traut), und sogar wer von welchen Teilen wie viel "Wissen" hat. Also ob es Teile gibt von denen vorgeblich nur ganz wenige Entwickler Ahnung haben. Diese Sachen können wir für den Reflex-Code derzeit nicht so extrahieren. Wir müssen erstmal mit den einfachen Metriken (Codezeilen/Kommentare/Komplexität), und deren Veränderung über die Zeit, leben. Bzw. ist da längst noch nicht alles erfasst, was schon möglich ist. Ich habe bei SST heute mal kurz angefragt, ob wir Zugang zu den entsprechenden Tools bekommen, um auch deren Reports im SQ einzupflegen. Das ist aber vermutlich viel Arbeit. Die gehen nämlich den anderen Weg: extrahieren alle Metriken aus SQ und weitere mit ihren Tools direkt aus dem SCM, um das Gesamtpaket dann als wachsende Softwarestadt[2] zu visualisieren. Was wir brauchen ist erstmal ein gutes Konzept für "Coverage", also das Ausführen von möglichst viel Code (line coverage) am besten in Verbindung mit Unit-Tests (test coverage). Das wird für die Embedded-Plattformen wirklich ordentlich wohl nur mit Simulatoren zu ermitteln sein. Das mspsim Projekt[3] wäre da wohl ein Kandidat für den MSP430. Für Atmel wäre das wohl entsprechend simavr[4]. Für Plattform "posix" sollten wir einfach mit gcov vom GCC experimentieren. Ist jemand mit zu viel Freizeit anwesend? ;) Grüße Stefan [1] http://www.tu-cottbus.de/fakultaet1/de/software-systemtechnik/ [2] http://opus4.kobv.de/opus4-UBICO/frontdoor/index/index/docId/8901 [3] https://github.com/mspsim/mspsim [4] https://gitorious.org/simavr/
