Hallo *, kurze Frage: Ich würde gerne die Sourcen von https://github.com/ttrftech/NanoVNA compilieren. Normalerweise arbeite ich mit VisualGDB und importiere eigentlich keine Projekte. An einen Import dieses Projektes ist aus meherern Gründen garn nicht zu Denken. Der erste ist das ich keine *.mk Dateien so einbinden kann wie es dieses Projekt möchte. Das nächste Problem ist Windows. In zwei der *.mk Dateien finden sich Aufrufe der Art HALCONF := $(strip $(shell cat halconf.h | egrep -e "\#define")) ifneq ($(findstring HAL_USE_DAC TRUE,$(HALCONF)),) HALSRC += $(CHIBIOS)/os/hal/src/hal_dac.c endif ifneq ($(findstring HAL_USE_EXT TRUE,$(HALCONF)),) HALSRC += $(CHIBIOS)/os/hal/src/hal_ext.c endif womit zur Copmilezeit Abhängigkeiten einfließen und die erste Zeile natürlich unter Windows nicht funktioniert. Ist es evtl. möglich zum Compilieren auf Windowssystemen (ich würde für dieses Projekt lieber eine zweite IDE auf Eclipsebasis unter Windows als ein Linuxsystem installieren) die Ausgabe von "cat halconf.h | egrep -e" in einer Textdatei abzuspeichern und diese als Eingabe für "HALCONF :=" zu benutzen?
Ich hab das früher mit Cygwin gemacht: Cygwin für die ganzen Kommandozeilentools incl. make und als Compiler die normale Windows-Installation des arm gcc. Man muss halt schauen daß alle Suchpfade richtig gesetzt sind, dann geht das hervorragend, auch mit Eclipse. All die Makefiles und Scripte die da zum Einsatz kamen konnte ich später unverändert(!) auf Linux weiterverwenden. Das war zu Windows 7 Zeiten. Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht schon eingebaut (oder nachinstallierbar) und damit sollte das genauso gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat. Ich selbst hab allerdings vorher schon den Ansprung geschafft und Windows kann mich jetzt gernhaben, daher kann ich nicht sagen wieviel Gefrickel das ist das zum Laufen zu bekommen, sollte aber trotzdem immer noch geschätzt 10 mal weniger Stress bereiten die Linux-Schicht zu verwenden als zu versuchen seine Makefiles und Scripte an die verkrüppelte Windows-Umgebung anzupassen oder gar beides zu unterstützen.
:
Bearbeitet durch User
Linux-VM und gut ist es. Dann hat man die guten Tools und braucht sich nicht mit Windows ärgern.
Die guten Tools gibt's auch einzeln für Windows: http://unxutils.sourceforge.net/ In der UnxUpdates.zip sind cat.exe und grep.exe dabei, man muss also noch grep.exe nach egrep.exe kopieren. Vorteil: man kann die Original-Dateien vom ChibiOS verwenden. Na gut, es sind nicht die allerneuesten Versionen, aber für den Zweck...
1 | $ wine grep --version |
2 | grep (GNU grep) 2.5.1 |
3 | |
4 | Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. |
5 | This is free software; see the source for copying conditions. There is NO |
6 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
:
Bearbeitet durch User
C. W. schrieb: > An einen > Import dieses Projektes ist aus meherern Gründen garn nicht zu Denken. > Der erste ist das ich keine *.mk Dateien so einbinden kann wie es dieses > Projekt möchte. Nun ja, schlechte Projekte sind eigentlich typisch für Github. Dort findet sich regelmäßig Zeugs, das derart viele externe Referenzen enthält, daß man es NUR mit einer einzigen IDE/Toolchain übersetzen kann. Portabilität gleich null. Aber wo kommen bei dir die .mk her? Ich finde dort erstmal nur NanoVNA-master\NANOVNA_STM32_F072\board.mk und der ganze .mk Schmonzes kommt von ChibiOS her. Dort gibt's die ja reichlichst. Wahrscheinlich kommst du nicht umhin, lediglich die Quellen .c und .h herzunehmen, dazu dann sowas wie board.* zu analysieren und dir einen sauberen Ersatz dafür selber zu schreiben. Anschließend geht jedoch das Suchen nach all den fehlenden Chibi-OS-Teilen los - alternativ das Rausschmeißen des ganzen Chibi-OS aus dem Projekt. 'Frohes Schaffen' kann man da nur sagen. Mit derartigen Projekten machen sich die Projekt-Autoren immer wieder selbst ihre Entwicklungen kaputt. W.S.
W.S. schrieb: > > Wahrscheinlich kommst du nicht umhin, lediglich die Quellen .c und .h > herzunehmen, dazu dann sowas wie board.* zu analysieren und dir einen > sauberen Ersatz dafür selber zu schreiben. Anschließend geht jedoch das > Suchen nach all den fehlenden Chibi-OS-Teilen los - alternativ das > Rausschmeißen des ganzen Chibi-OS aus dem Projekt. > > 'Frohes Schaffen' kann man da nur sagen. Mit derartigen Projekten machen > sich die Projekt-Autoren immer wieder selbst ihre Entwicklungen kaputt. > > W.S. Wieder mal der typische W.S. Stuss. Der Vorschlag von PittyJ ist deutlich sinnvoller.
Ich werde mal probieren ohne das Chibios auszukommen und stattdessen Freertos drunter zu schnallen. Das bedingt zwar das ich alle zukünftigen Deltas händisch nachpflegen muss aber dafür bin ich dann in meiner Version "zuhause". Spätestens wenn ich mal eine eigene Hardware mit besserem HF-Teil und evtl. anderer CPU benutzen will gehen die Diskussionen mit Chibios und dessen HAL wieder los.
C. W. schrieb: > Ich werde mal probieren ohne das Chibios auszukommen und > stattdessen Freertos drunter zu schnallen. Das ist von allen möglichen Lösungswegen vermutlich einer der schmerzhaftesten. Du benötigst neben dem RTOS auch noch einen HAL. Ja, natürlich kannst du weiterhin den von ChibiOS nehmen aber das löst dann dein Problem nicht. Du kannst also ruhig das gesamte Projekt neu schreiben. Für das bisschen Shell-Script willst du das allen ernstes auf dich nehmen? Alternativen gibt es genug und einige wurden ja auch schon hier genannt: WSL, MSYS2, VM,... W.S. schrieb: > Nun ja, schlechte Projekte sind eigentlich typisch für Github. Dort > findet sich regelmäßig Zeugs, das derart viele externe Referenzen > enthält, daß man es NUR mit einer einzigen IDE/Toolchain übersetzen > kann. Portabilität gleich null. Das ist völliger Käse. ChibiOS lässt sich dank des Makefile-basierten Builds auf so ziemlich jedem Betriebssystem (Windows, OS X, Linux, etc.) mit so ziemlich jedem Compiler übersetzen (GCC, Keil und IAR werden ab Werk unterstützt) und das bei einer sehr großen Auswahl unterschiedlicher Prozessorarchitekturen. Diesen Variantenreichtum kann man dann entweder über ifdef-Orgien mit dem CPP erschlagen oder man macht das eben über ein gescheites Build-System, wie z.B. Make. Ich halte letzteres für wesentlich sinnvoller.
De eigentliche Buildvorgang ist nicht das Thema. Auf eirgeneiner Linuxmaschine im Netzt kann ich das ganze bauen lassen (der eigene Rechner mit VM scheidet wegen der Unfähigkeit der eigenen CPU für VMs aus). Viel interessanter wäre welche IDE/Editor in der Lage ist während dem Schreiben das alles schon richtig aufzulösen um z.B. mit Rechtsklick und einer Auswahl zur entsprechenden Datei zu springen in der z.B. eine Funktion definiert wird. Die sache mit dem cat/grep ließe sich lösen indem ich das einmal manuell ausführe und das Ergebnis in einer Datei speicher die ich anstelle des Shell-Befehls als Eingabe benutze.
:
Bearbeitet durch User
Christopher J. schrieb: > Das ist völliger Käse. Na klar - und der TO hat hier aus lauter Übermut diesen Thread eröffnet. Und das besagte Projekt läßt sich problemlos überall und auf allen Toolchains ohne Komplikationen übersetzen. Und .mk Dateien sind ebenfalls allen Programmen bekannt. Sag mal, geht's noch? W.S.
W.S. schrieb: > Na klar - und der TO hat hier aus lauter Übermut diesen Thread eröffnet. > Und das besagte Projekt läßt sich problemlos überall und auf allen > Toolchains ohne Komplikationen übersetzen. Und .mk Dateien sind > ebenfalls allen Programmen bekannt. Ich bin da bei Christopher. Das Projekt ist offensichtlich komplett lauffähig und es gibt Vorraussetzungen wenn man es so nachbauen möchte. Will man etwas anderes benutzen, dann muss man selber Hand anlegen. Fertig. Das macht das Original in keinster Weise schlechter. Wenn man das Buildsystem nicht mag ist das PP. Es lässt sich vielleicht mit FreeRTOS umsetzen, aber die verwendeten Komponenten müssen evtl. auch threadsafe sein. Allerdings wird im Linkerscript auch gegen die Newlib Nano gelinkt die nicht threadsafe ist. C. W. schrieb: > Ist es evtl. möglich zum Compilieren auf Windowssystemen (ich würde für > dieses Projekt lieber eine zweite IDE auf Eclipsebasis unter Windows als > ein Linuxsystem installieren) da gibt es mit https://osdn.net/projects/chibios/releases/70767 doch schon ein vorkonfiguriertes Eclipse.
Johannes S. schrieb: > a gibt es mit > https://osdn.net/projects/chibios/releases/70767 > doch schon ein vorkonfiguriertes Eclipse. Das hat schon etwas von "Berg zum Propheten kommen".
Also prinzipiell funktioniert der Build mit Chibistudio, aber offenbar will ich die dämlichste Kombination benutzen die es gibt. Ich fasse mal zusammen: Build im Chibistudio - geht out of the box Build unter Linux - geht out of the box Build im VisualStudio mit VisualGDB - geht nicht out of the box Segger J-Link im Chibistudio - geht nicht out of the box Segger Systemview (wenn man mal tiefer einsteigen will) - geht nicht out of the box Ich werde jetzt mal hier und da ein paar kleinere Änderugnen an dem Projekt für mich im Chibistudio machen, aber die Endlösung wird es nicht werden. Es fühlt sich irgendwie nich gut an und ich habe kein Lust noch groß Aufwand für das Werkzeug zu betreiben.
C. W. schrieb: > Segger J-Link im Chibistudio - geht nicht out of the box Das sollte eigentlich gehen da Chibistudio ja auch ein Eclipse mit Plugins ist. Eventuell für J-Link noch ein Plugin installiert oder angepasst werden. Aber ich bin auch weg von Eclipse, die Konfiguration da ist zu undurchsichtig. Wenn der J-Link da installiert ist muss eine passende Lauch Configuration angelegt werden.
Mal ne Frage dazu: Wozu soll denn eigentlich das Chibi-OS in diesem Falle dienen? Also welchen wichtigen und unverzichtbaren Job führt das hier aus? Es ist ja im Grunde nur eine relativ geradlinige Anwendung, die da ausgeführt werden soll. Ist das Chibi-OS nur deshalb dabei, weil die Erfinder der Firmware gern mit einem RTOS programmieren - oder gibt es echte harte Gründe? W.S.
wer soll dir hier eine Antwort darauf geben? Das solltest du die Autoren fragen.
Mal wieder ein typischer W.S. Post! Erst Müll texten und dann einen Safe Space wollen, wenn mal leichter Gegenwind kommt. Offensichtlich hast du auch mal wieder keine Ahnung von nichts, aber willst mitreden. Reichts inzwischen nicht mal mehr zur Bedienung einer Suchmaschine deiner Wahl? .mk Dateien sind nichts weiter als Makefiles, nur freundlich für Windowsuser wegen der Dateiendung. Windows erkennt den Dateityp an der Endung und mit .mk kannstes mit einem Editor deiner Wahl verknüpfen. make(.exe) ist die Dateiendung egal und daher läuft das auch so. In dem Sinne: W.S. schrieb: > Sag mal, geht's noch?
Bernd K. schrieb: > Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht > schon eingebaut (oder nachinstallierbar) und damit sollte das genauso > gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat. Leider geht das nicht so schön wie mit CygWin. Die Bash führt keine Windows Kommandos aus und die CMD.exe führt keine Linux Kommandos aus.
Stefan ⛄ F. schrieb: > Bernd K. schrieb: >> Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht >> schon eingebaut (oder nachinstallierbar) und damit sollte das genauso >> gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat. > > Leider geht das nicht so schön wie mit CygWin. Die Bash führt keine > Windows Kommandos aus Was? Hier (erstbester Google-Fund) https://www.howtogeek.com/285082/how-to-run-windows-programs-from-windows-10s-bash-shell/ steht sehr wohl daß man von bash aus windows exe starten kann! Also einfach vorher die richtigen Umgebungsvariablen setzen (zum Beispiel $CC oder $PATH) und das Makefile müsste den in Windows installierten gcc finden und starten können! Oder etwa nicht?
Bernd K. schrieb: > daß man von bash aus windows exe starten kann! Ok, das scheint neu zu sein. Als ich das damals evaluierte, ging das noch nicht.
Stefan ⛄ F. schrieb: > Ok, das scheint neu zu sein. Als ich das damals evaluierte, ging das > noch nicht. Ja, ich glaub das war in der allerersten Version die sie veröffentlicht haben. Damals sagte ich noch wenn die das ernsthaft so lassen wollen kann mans auch komplett in der Pfeife rauchen. Da haben sie dann anschließend noch nachgebessert.
C. W. schrieb: > Ich werde jetzt mal hier und da ein paar kleinere Änderugnen an dem > Projekt für mich im Chibistudio machen, aber die Endlösung wird es nicht > werden. Es fühlt sich irgendwie nich gut an und ich habe kein Lust noch > groß Aufwand für das Werkzeug zu betreiben. Ich entwickle unter ChibiOS und verwende dazu Atollic, allerdings mit Makefile-Projekt. Die automatische Auflösung der C-Namen ist etwas hakelig, da musste ich ziemlich von Hand nacharbeiten. Dafür lief der Debugger mehr oder weniger out-of-the-box. Angenehm an ChibiOS finde ich die saubere Integration des HAL. Die Doku dagegen krankt an einem chronischen Mangel an Beispielen. Leider.
C. W. schrieb: > Viel interessanter wäre welche IDE/Editor in der Lage ist während dem > Schreiben das alles schon richtig aufzulösen um z.B. mit Rechtsklick und > einer Auswahl zur entsprechenden Datei zu springen in der z.B. eine > Funktion definiert wird. Das Problem ist, dass deine IDE (egal welche) keine Chance hat alles aufzulösen, wenn sie keine Informationen über den Build-Vorgang hat. Das ist ja gerade das Ding bei diesen ganzen IDEs: Man gibt explizit jede Datei, jeden #define, etc. an und wenn man sein Projekt dann einmal gebaut hat, kann der Indexer daraus noch weitere Schlüsse ziehen, womit dann Autovervollständigung, Linting, etc. funktionieren. Bei den ganzen Eclipse-basierten IDEs funktioniert das dann leidlich gut, selbst bei Projekten wie ChibiOS, libopencm3 oder Nuttx, die alle mehrere Plattformen (und damit automatisch auch redundanten Code) in einem einzigen Repository haben. Wie das genau bei VisualGDB ist kann ich nicht sagen, da ich das noch nie benutzt habe. Was VisualGDB ganz sicher nicht mitbringt sind die erwähnten Unixtools. Um die zu bekommen würde ich bei Win10 definitiv WSL installieren. Einfacher kann man als Windowsuser wirklich nicht an *nix-Werkzeuge kommen. Kannst du aber halten wie du willst. Zurück zum eigentlichen Problem, dass die IDE den Code nicht zu 100% richtig "versteht". Man kann natürlich bei Eclipse (und vermutlich auch VisualGDB) jeden einzelnen #define von Hand einfügen aber das ist eine ziemliche Sisyphos-Arbeit. Es gibt aber zum Glück die Möglichkeit mittels einer "compilation database" alle Compileroptionen, incl. #defines, #includes, etc. zu exttahieren. Das klingt erstmal kompliziert, ist aber tatsächlich nur eine Textdatei, die JSON enthält (compile_commands.json). Mit Hilfe dieser JSON-Datei kann nun eine IDE optimal für Autovervollständigung, Linting, etc sorgen. IDEs die das unterstützen sind: - QT Creator mit CompilationDatabaseProjectManager Plugin (mein persönlicher Favorit) - VIM, Atom oder VS Code mit YouCompleteMe Plugin - VS Code mit C/C++-Tools von MS - vermutlich noch viele weitere, die ich nicht kenne. Vielleicht sogar VS? Es gibt verschiedene Möglichkeiten an diese JSON-Datei zu kommen. Manche Build-Systeme, zum Beispiel CMake können die von sich aus erzeugen. Ist das nicht der Fall, zum Beispiel bei Make, gibt es Programme die den Build-Prozess belauschen und dadurch die Compileroptionen extrahieren. Ich benutze dafür scan-build (https://github.com/rizsotto/scan-build) weil das mittels pip sehr einfach zu installieren ist. Dann kann man mittels "intercept-build make" seine compilation database erstellen. scan-build baut auf "bear" (vom gleichen Autor) auf, um die compilation database zu erstellen, was man auch einzeln nutzen kann. Hier hab ich auf die schnelle eine Seite mit einer guten Übersicht gefunden: https://sarcasm.github.io/notes/dev/compilation-database.html Ich hoffe mal, dass dich dieser Post nicht erschlägt. Im Grunde ist es alles recht einfach, wenn man es einmal verstanden hat. In diesem Sinne: > Sag mal, geht's noch? Ja, geht alles bestens ;)
Christopher J. schrieb: > Das Problem ist, dass deine IDE (egal welche) keine Chance hat alles > aufzulösen, wenn sie keine Informationen über den Build-Vorgang hat. Eclipse kann den Output des Buildvorgangs parsen. Es sieht jedes einzelne -I und jedes -D bei jedem Compileraufruf und weiß dann wo die Includes zu suchen sind und welche Symbole definiert sind. Wenn man diesen Modus in Eclipse aktiviert und dann einmal einen vollständigen Build startet konfiguriert sich Eclipse komplett selbst. So kann man also hervorragend mit Makefile-Projekten arbeiten. Es gibt noch ein paar andere IDEs die können das ebenfalls, ich gehe sogar so weit daß ich jede C-IDE die das nicht kann als nicht auf dem aktuellen Stand der Technik befindlich betrachte und keine Zeit damit verschwende. Alle meine eigenen Projekte sind IDE-agnostisch und werden mit Kommandozeilentools auf der Kommandozeile gebaut. Die IDE (egal welche) hat damit automatisch zurechtzukommen (die guten können das) oder sie ist für die Tonne.
:
Bearbeitet durch User
Bernd K. schrieb: > Wenn man diesen Modus in Eclipse aktiviert und dann einmal einen > vollständigen Build startet konfiguriert sich Eclipse komplett selbst. > So kann man also hervorragend mit Makefile-Projekten arbeiten. Ich sagte ja auch, dass man einigermaßen damit arbeiten kann. Leider ist Eclipse meiner Erfahrung nach nicht so optimal darin, wenn es um Namensauflösungen, etc. geht. Der Linter hat so oft Falschmeldungen fabriziert, dass ich ihn meistens einfach abgeschaltet habe aber ymmv.
Christopher J. schrieb: > Leider ist > Eclipse meiner Erfahrung nach nicht so optimal darin, wenn es um > Namensauflösungen, etc. geht. Derartiges ist mir noch nicht aufgefallen, meine Erfahrung ist wenn nichts falsch konfiguriert ist und wenn etwas der Compiler findet dann findet Eclipse es auch. Das Problem ist nur es gibt einige Sachen oder Einstellungen mit denen Eclipse sich dann wieder selbst sabotieren kann, das bekommt man erst in den Griff wenn man ein paar Jahre intensive Erfahrung mit den ganzen Zicken gemacht hat die es potentiell machen kann oder immer einen Eclipse-Guru in Rufweite hat, das ist auch mein Hauptkritikpunkt seit Ewigkeiten, das stecken auch noch ein paar Bugs drin um die sich einfach keiner kümmern will oder kann. Dennoch kenne ich leider keine andere freie C-IDE die so einen Leistungsumfang (insbesondere Codeverständnis) hat wie Eclipse. So pflege also auch ich eine Haßliebe zu Eclipse seit viele Jahren, manchmal könnte auch ich es direkt aus dem Fenster katapultieren aber ich finde keinen vollwertigen Ersatz, irgendwas essentielles an das ich mich schon zu sehr gewöhnt habe um es ersatzlos aufzugeben fehlt immer.
Ich oute mich auch mal als QtCreator-Fan. Durchaus auch mal ohne das CompilationDatabaseProjectManager Plugin. Man muß dann eben die .includes und .config-Files parallel zum Makefile händisch pflegen. Bei nicht allzu grossen Projekten problemlos möglich und im Gegensatz zu Eclipse CDT leicht zu durchschauen, wie alles zusammenhängt.
Bernd K. schrieb: > Dennoch kenne ich leider keine andere > freie C-IDE die so einen Leistungsumfang (insbesondere Codeverständnis) > hat wie Eclipse. Markus F. schrieb: > Ich oute mich auch mal als QtCreator-Fan Ich habe einen Bruder, der heißt Markus F. Aber wenn der inzwischen mit Elektronik bastelt wäre ich sehr überrascht. Ich stelle mich auch auf deine Seite, oute mich ebenfalls. Für AVR nutze ich die Qt Creator IDE so: http://stefanfrings.de/avr_tools/index.html#qtcreator (wird bei STM32 wohl ähnlich gehen).
Stefan ⛄ F. schrieb: > Schau Dir mal Qt Creator an, dass eignet sich auch ganz gut für > Mikrocontroller. Hat es ein Plugin für J-Link Debugging und hat es ein Plugin um während des Debuggens alle Bits in allen Peripherie-Registern namentlich anzeigen oder verändern zu können? Dieses Feature ist zu mächtig, das will ich nicht aufgeben!
Markus F. schrieb: > Man muß dann eben die .includes und .config-Files parallel zum Makefile > händisch pflegen. Das ist ein absolutes No-Go. Ich will die Konfigurationen nicht doppelt pflegen. Alle IDEs die nicht in der Lage sind die Konfiguration, die Defines und Includepfade aus einem Makefile-Projekt automatisch selbst zu ermitteln und automatisch aktuell zu halten scheiden schon in der ersten Runde aus.
Bernd K. schrieb: > Stefan ⛄ F. schrieb: >> Schau Dir mal Qt Creator an, dass eignet sich auch ganz gut für >> Mikrocontroller. > > Hat es ein Plugin für J-Link Debugging und hat es ein Plugin um während > des Debuggens alle Bits in allen Peripherie-Registern namentlich > anzeigen oder verändern zu können? Dieses Feature ist zu mächtig, das > will ich nicht aufgeben! Keine Ahnung, ich habe mit Qt Creator noch keine Mikrocontroller debuggt. Das scheint zumindest vorgesehen zu sein: https://doc.qt.io/qtcreator/creator-developing-baremetal.html https://electronics.stackexchange.com/questions/212018/debugging-an-arm-stm32-microcontroller-using-qt-creator
Bernd K. schrieb: > Das ist ein absolutes No-Go. "Muß" war hier falsch gewählt. "Kann" wäre richtig gewesen. Mit dem Plugin geht's ja auch so.
Bernd K. schrieb: > Hat es ein Plugin für J-Link Debugging Es gibt kein dediziertes J-Link Plugin, sondern lediglich ein "Bare Metal"-Plugin. Damit kann man auch mit OpenOCD debuggen. Ob der J-Link GDB-Server explizit unterstützt wird weiß ich nicht genau. Bernd K. schrieb: > hat es ein Plugin um während des Debuggens alle Bits in allen > Peripherie-Registern namentlich anzeigen oder verändern zu können? Das gibt es so leider nicht. Wenn man mit -g3 kompiliert, kann man aber mit dem GDB auch Makros auflösen, d.h. man kann sich z.B. den Wert von TIM1->CNT anzeigen lassen. Das geht sogar von der Konsole aus. Leider ist das sehr friemelig, wenn man z.B. ein Statusregister ausliest, weil da eine Dezimalzahl nicht gerade aussagekräftig ist. Das ist aus meiner Sicht die größte Schwachstelle von QT Creator (neben dem nicht so tollen VIM-Modus).
Bernd K. schrieb: > Eclipse kann den Output des Buildvorgangs parsen. Es sieht jedes > einzelne -I und jedes -D bei jedem Compileraufruf und weiß dann wo die > Includes zu suchen sind und welche Symbole definiert sind. Wenn man > diesen Modus in Eclipse aktiviert und dann einmal einen vollständigen > Build startet konfiguriert sich Eclipse komplett selbst. Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare ersparen.
Max G. schrieb: > Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare > ersparen. Da schließe ich mich mal an. Den habe ich bisher auch noch nicht gefunden.
Angehängte Dateien:
-
bop.png
130 KB
Max G. schrieb: > Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare > ersparen. Da die Defaulteinstellung für cross-compiler unbrauchbar ist (regexp greift nicht) ist diese ganze Funktionalität in Embedded-Kreisen eher unbekannt. Es muss die Einstellung "Compiler Command Pattern" angepasst werden und sobald das geschehen ist fängt es auf magische Weise an zu funktionieren! Die Ergebnisse kann man dann im Tab "Entries" auf der selben Einstellungsseite sehen nachdem ein vollständiger Build mal durchgelaufen ist. Die ganzen Sachen die man auf der Seite "Paths and Symbols" manuell eingetragen hat sollte man dann wieder alle entfernen. -- Wichtig: Wenn man ein existierendes Makefileprojekt erneut importiert (zum Beispiel auf nem anderen Arbeitsplatz, "import existing project into workspace") dann muss man diese Einstellung erneut kontrollieren denn beim Importvorgang mach Eclipse diese Einstellung kaputt (seit Jahren schon gemeldeter Bug, passiert leider nichts). Die schnellste Methode nach dem Import ist: Frisch importiertes Projekt wieder schließen, git reset --hard, Projekt wieder öffnen. Das passiert nur beim Import, man muß es nur einmal machen, deshalb hält sich der Ärger in Grenzen, aber man muß halt nur darüber Bescheid wissen.
:
Bearbeitet durch User
Bernd K. schrieb: > Da die Defaulteinstellung für cross-compiler unbrauchbar ist (regexp > greift nicht) ist diese ganze Funktionalität in Embedded-Kreisen eher > unbekannt. Es muss die Einstellung "Compiler Command Pattern" angepasst > werden und sobald das geschehen ist fängt es auf magische Weise an zu > funktionieren! Eben getestet. Sollten wir uns mal begegnen, bin ich dir mindestens ein Bier schuldig. Seriously. Das war der beste Tipp seit langem. Danke!
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.