Hi, benutz hier jemand Sourcetrail mit AVR oder ARM prozessoren? Ich bin durch Zufall auf Sourcetrail gestoßen und wollte erst einmal fragen ob das für C gut funktioniert. Ich dachte ich frage mal lieber bevor ich mich da stundenlang mit beschäftige und dann merke das es nichts taugt. Wenn es sehr gut arbeitet, dann interessiere ich gerne viele Stunden. Aktuell nutze ich Emblitz und Codeblocks mit dem GCC dahinter. Als zusätzliche Software habe ich noch eine alte Version (15 Jahre alt) von DAC (development assistance for C). Das ist sowas wie Sourcetrail. Also hat jemand Erfahrung mit Sourcetrail?
Ich würde sagen, es ist wie immer. Wenn jemand etwas Neues mit "graphischer Unterstützung" sucht, kann er es probieren. Wer mit seinen Werkzeugen optimal klar kommt, für den ist es nur viel zusätzliche Klick Arbeit. Welcher Typ bist Du? Hättest Du vermutlich in 4 Stunden selbst herausgefunden. Sagen kann dir das vermutlich so oder so keiner.
Peter schrieb: > Also hat jemand Erfahrung mit Sourcetrail? Ich nicht. Was macht das? Ich würde angesichts meiner inzwischen fast 40-jährigen Programmiererfahrung und der Tatsache, dass mir in all der Zeit "sourcetrail" nie untergekommen ist und ich es auch nie vermißt habe mal getrost davon ausgehen: man braucht es auch nicht.
Ihr scheint ja super perfekte Programmierer zu sein. Macht keine Fehler, kennt euch noch in 5 Jahren im Code aus und habt fremden Code nach 5 Minuten verstanden. Mein Respekt! Ich gehöre nicht dazu, ich brauche dafür Tools die mir dabei helfen. Neben den statischen Code check ( compiler, lint,...) gibt es halt noch so nette Programme die noch einen Schritt weiter gehen und einem zeigen wer was wo wie benutzt. So was nutze ich nun seit 21 Jahren und bin halt nun über Sourcetrail gestolpert. Und jetzt wollte ich eigentlich nur wissen ob das jemand einsetzt und wie die Erfahrung damit so ist.
Damit hast Du doch die Frage beantwortet, dass es sinnvoll für dich ist. Viel Erfolg und gute Erfahrung! Mir reichten bei fremden Programmen bis jetzt die Header Dateien und wenn es zu unübersichtlich wird, ein Zettel und ein Stift.
Ich hatte das mal ausprobiert. Wenn man täglich mit neuer unbekannter Sofware >100000 Zeilen hantieren muss, mag das hilfreich sein. Für alle paar Jahre mal ist es wie mit allen solchen tools: bis man sich da wieder eingearbeitet hat, hat man die fremde Software auch so verstanden. Oliver
Hört sich nicht schlecht an, habe ich bisher nicht genutzt. Die Editoren/IDE bieten mittlerweile viel Hilfe um schnell zu Deklarationen zu springen oder als Vorschau anzuzeigen. Oder im Debugger den callstack anzeigen, da steht die Wahrheit. Solche Tools waren früher sehr teuer, das hier scheint nur Spenden haben zu wollen?
Peter schrieb: > Hi, > benutz hier jemand Sourcetrail mit AVR oder ARM prozessoren? [...] > Ich bin durch Zufall auf Sourcetrail gestoßen und wollte erst einmal > fragen ob das für C gut funktioniert. [...] > Also hat jemand Erfahrung mit Sourcetrail? Ich habe SourceTrail für meine STM32 C++ Projekte ausprobiert und nutze es hin und wieder. Es hat auf Anhieb funktioniert und kam problemlos sowohl mit C als auch mit C++ Template Code zurecht. Das initiale Setup war weitestgehend selbsterklärend und innerhalb sehr kurzer Zeit erledigt. Als einzelner Hobby-Anwender fehlt mir der Vergleich zu kommerziellen Tools. Für ähnliche Zwecke habe ich bislang die Code Navigation von Netbeans, Eclipse u. Visual Studio Code verwendet. Im Vergleich dazu finde ich SourceTrail deutlich besser. Mit "besser" meiner ich: Findet alle Referenzen, was bei den anderen genannten Tools für C++ Templates nicht selbstverständlich ist. Nachteil in meinen Augen: Es ist ein separates Werkzeug mit eigener GUI. Insgesamt kann ich nur empfehlen es auszuprobieren, v.a. auch weil die Einstiegshürde extrem niedrig ist.
Installiert ist es schon mal. Habe jetzt nur die Beispiele getestet und auf den ersten Blick ist es noch besser wie das Tool (DAC ca. 1000€) was ich jetzt Einsetze. Gut das ist auch von mir seit 15 Jahren nicht aktualisiert. Das man noch einen Editor hat ist halb so wild, meistens nutzt man dann nur den und nur zum kompilieren und debuggen nimmt man die anderen. Oder hat ein make System dafür. Auch ein Programm mit nur 500 Zeilen kann man unübersichtlich machen oder da steckt so viel dahinter das man schon nach Monaten suchen kann. Aber die super Programmierer haben auch mit Millionen Zeilen kein Problem unter VI. Wenn man privat fremden Code ansieht ist das immer was anderes als wenn ein Kunde einem so was vorsetzt. Da kann man schlecht sagen alles mist da steige ich nicht durch. Und bei meinem eigenen Code ist so etwas auch eine Hilfe.
> meiner inzwischen fast 40-jährigen Programmiererfahrung
Vor fuenfzig Jahren gab es zum "durchblickenden" Editieren xcoral.
Das war, um in groesseren Sourcecodeverhauen einen Ueberblick
zu bekommen, schon recht hilfreich.
Den xcoral Sourcecode sollte man auch heute noch irgendwo aufstoebern
koennen. Braucht halt X und mwm wenn ich mich dunkel entsinne.
Der Editor davon, war aber eben nur "Standard" und nicht
das was taeglich benutzen wollte.
Man benötigt ein Compile Commands JSON File, damit Sourcetrail nachvollziehen kann wie das Sourcecode gebaut wird. Siehe hier: https://clang.llvm.org/docs/JSONCompilationDatabase.html Entweder kann es das Build System selbst generieren, wie etwa Cmake oder waf.io es kann, oder man muss es irgendwie mitschneiden. Siehe Beispiele hier: https://sarcasm.github.io/notes/dev/compilation-database.html Unter Linux empfehle ich einfach Bear: https://github.com/rizsotto/Bear Für Windows funktioniert compiledb, wenn make beim bauen zur Verwendung kommt: https://github.com/nickdiego/compiledb Eclipse CDT zb. generiert Makefiles und ruft dann make auf, also sollte compiledb auf Windows funktionieren. Wichtig ist, dass ein Compiler benutzt wird, was Sourcetrail versteht, weil es muss die Define Flags und alles mögliche verstehen, was per optionen dem Compiler weitergereicht werden. Mit TI's hauseigenem arm-cgt geht es deswegen nicht so toll. Mit gcc und llvm/clang sollte es keine Probleme geben. Ansonsten ist so ein Compile Commands JSON File eine tolle Sache, wenn es zur Hand ist kann man gleich mit Cppcheck + Clang-tidy den Sourcecode für verschiedene Fehler überprüfen.
Ich habe keine Probleme auch ohne Programm Unterstützung unter 2 Editoren alles neu anzulegen. Ist zwar etwas umständlich aber man macht das pro Code ja nur einmal. So schlimme Definition hab ich nicht bei mir drin. Code ausblenden durch defines ist das wichtigste was der können muss, das machen leider heute immer noch nicht alle richtig. Morgen geht es mal an ein kleines avr Projekt, dann sehe ich ja wie gut Sourcetrail so ist.
So ich habe getestet! Negativ: Als Editor /IDE unbrauchbar, weil es kein Editor ist. Somit für mich als alltägliches Tool durchgefallen. Ich denke das selbst wenn Sourcetrail unter anderen Editoren so als Zusatz läuft (geht wohl mit einigen), das es nicht hilft bei der täglichen Entwicklung. Die meisten Editoren können mir auch ohne Zusatzhilfe sagen wo eine Variable defininert ist und wo die im Code benutzt wird. Positiv: Um in fremden Code sich zurecht zufinden ist Sourcetrail sehr gut. Dafür werde ich es auf jedenfall einsetzen. Für den alltäglichen gebrauch (C-Code) werde ich bei DAC bleiben. Um grössere Projekte von Kunden oder aus dem Netz kennen zulernen werde ich versuchen Sourcetrail einsetzen. Ob es da dann auch das leistet was es soll wird sich leider erst dann zeigen. Aber mit dem Projekt (18 Dateien) was ich zum testen benutzt hatte sah das schon recht gut aus. Was ich auf die schnelle nicht hinbekommen habe ist das die ganzen Prozessor Register richtig aufgelöst wurden. Somit hatte ich über 300 Fehler, die aber nicht weiter störten. Schade das hier mir keiner gleich gesagt hatte "Das ist kein EDITOR". Dann hätte ich mir das testen vielleicht gespart.
Peter schrieb: > Schade das hier mir keiner gleich gesagt hatte "Das ist kein EDITOR". > Dann hätte ich mir das testen vielleicht gespart. Konnte ja niemand wissen, daß du nicht lesen kannst. Schreib das das nächste mal einfach dazu. Oliver
So was überließ man schnell, wenn man gleichzeitig mehr auf die Bilder achtet und die ganzen Texte sieht was und wie das alles kann. Da ist so eine Info das man nur ansehen kann schnell mal überlesen.
Zum Thema "compile_commands.json" kann ich nur sagen, dass das in jeglicher Hinsicht das beste ist, was auf dem Feld der C/C++-IDEs in den letzten Jahren passiert ist. Damit kann eine IDE bzw. ein Linter, etc. wirklich genau nachvollziehen wie ein Projekt gebaut wurde (inkl. aller #defines, etc., für jede Datei einzeln!) und das unabhängig vom Buildsystem (Make, CMake, Scons, etc.). Für das erzeugen der "compilational database" nutze ich Scan-Build: https://github.com/rizsotto/scan-build Das basiert wiederum auf Bear, hat aber den Vorteil, dass es einfach mittels pip zu installieren ist und sollte (theoretisch, habe keine eigene Erfahrung) auch unter Windows laufen. Außerdem bringt es noch gleich einen static-analyzer mit, den ich jedoch gar nicht explizit benutze, weil der bei mir in der IDE (QT-Creator) sowieso integriert ist (basiert beides auf Clang).
Christopher J. schrieb: > der bei mir in der IDE (QT-Creator) sowieso integriert ist > (basiert beides auf Clang). Warum dann noch ein zusätzliches tool zur Erzeugung der Compile Database? Oliver
Bitte 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.