Eclipse + bereits vorhandener Code: falsche Vorgehensweise?

[timertick_t (Gast)]

Hab hier Eclipse + ARM plugin und versuche Code auszuprobieren, z.B. 
diesen hier:
https://github.com/devthrash/STM32F4-examples/tree/master/USART

Wenn ich ein neues Projekt anlege, dann mache ich das mit dem Wizard so:
File -> New -> Other... -> Make Project With Existing Code
Ich trage dann im nächsten Reiter den Projektnamen und den Ort der 
Dateien ein. Das war's. Makefile ist im Code des Projekts dabei.

Resultat: Ich bekomme viele '... could-not-be-resolved' Fehler. Auch 
wird erst gar kein Debug oder Release-Ordner angelegt. Was mache ich 
falsch?

[Bernd K. (prof7bit)]

Nächste Schritte:

1. Mache daß es kompiliert in Eclipse

2. Konfiguriere das Build-Output-Parsing so daß Eclipse alle 
Include-Pfade aus dem Build-Output herausklauben kann.

Fertig.

---------------

Zu 1 musst Du irgendwo den Build-Befehl einstellen (make) und evtl den 
Build-Ordner (den Pfad wo sich das Makefile befindet).

Zu 2: Du musst evtl. die Regexp ändern die er verwendet um eine Zeile zu 
erkennen die mit arm-none-eabi-gcc anfängt, da erkennt er standardmäßig 
nur gcc, das ist ein Bug in Eclipse, die standardmäßige regexp die da 
drin steht ist hirntot.

Danach werden nach dem ersten Build alle Fehler verschwunden sein weil 
Eclipse dann alle Include-Pfade und alle nötigen Defines kennt.

[Oliver S. (oliverso)]

timertick_t schrieb:
> Resultat: Ich bekomme viele '... could-not-be-resolved' Fehler.

Wenn die Melsungen beim kompilieren/linken auftreten, dann sind das 
linker-Fehlermeldungen zu fehlenden libs. Da ist dann dein externes 
makefile fehlerhaft.

Insofern immer erst mal bei solchen Projekten ganz ohne Eclipse von der 
Kommandozeile ein make ausprobieren. Wenn das funktioniert, klappt es 
auch mit Eclipse. Bei makefile-Projekten ist Eclipse ja nur ein Editor, 
der make aufruft.

Oliver

[timertick_t (Gast)]

Uff. Ich glaub ich geb auf;-) Je mehr ich mich damit beschäftige umso 
verwirrender wird da ganze. Das Eclipse-Plugin zielt von Hause aus auf 
'HAL-bezogenen' Code (viele verschachtelte xxxHALxxx.h). Aber eigentlich 
sollte der in dem Cube-Paket von ST sein... Das wiederum ist aber 
ziemlich alt und ohne HAL-Basis, und die neue Version hat entpackt 
600MB... Die mag ich nicht so recht anlangen.
Sämtliche Beispiele die ich fand sind nicht lauffähig; immer hängt's am 
Verwalten und am makefile des Codes. Zehn Stunden nervenaufreibender 
Quatsch für die Katz. Unbezahlbar.
Da lob ich mir Atmel. Alle ASF-Beispiele gehen auf Anhieb, keine 
Inkombatibilitäten. Grummel.


PAUSE.

[hp-freund (Gast)]

Nimm doch erst mal was kleines zum Start:

https://github.com/progranism/stm32f4-gcc-template

die zip hat gerade mal 460k.
Wenn der compiler läuft, einfach auspacken, make und fertig...

[Bernd K. (prof7bit)]

timertick_t schrieb:
> Das Eclipse-Plugin zielt von Hause aus auf
> 'HAL-bezogenen' Code (viele verschachtelte xxxHALxxx.h).

Nein, das kann man so nicht sagen, nur die mitgelieferten Templates (der 
Wizard der erscheint wenn Du ein neues Projekt erzeugst) legen das 
nahe. Es funktioniert jedoch auch problemlos mit jedem x-beliebigen 
Makefile-Projekt, auch (und gerade!) mit solchen ohne HAL oder sonstigen 
libs, da wirds sogar noch einfacher!

Es läuft auf 4 in sich geschlossene und halbwegs überschaubare Schritte 
hinaus die einer nach dem anderen in der folgenden Reihenfolge 
durchgeführt werden müssen.

1. Sicherstellen dass es an der Kommandozeile mit make all kompiliert.

2. Import in eclipse ("Existing code as makefile project")

3. Sicherstellen dass aus Eclipse heraus immer noch kompiliert, dass das 
das Makefile aufgerufen werden kann genauso wie zuvor bereits auf der 
Kommandozeile.

4. Nun muss Eclipse noch über die ganzen Include-Pfade und Defines 
informiert werden damit es sinnvoll als Editor verwendet werden kann, 
damit die roten Wellenlinien alle verschwinden, damit Autocomplete 
vernünftig funktionieren kann, damit unzutreffende ifdefs ausgegraut 
werden und bedingte includes korrekt geparst werden.

Punkt 4 ist der Schritt in dem am meisten Arbeit steckt bzw der größte 
Frustfaktor, aber auch das ist relativ straightforward. Du kannst 
entweder per Hand alle notwendigen Include-Pfade angeben (alles was in 
den -I Optionen beim gcc-Aufruf auftaucht) und alle Defines (alles was 
in -D optionen beim gcc-Aufruf mitgegeben wird), schau Dir hierzu an was 
alles auf der Konsole erscheint beim Build des Projekts es interessiert 
was alles genau an den gcc übergeben wird. Das kommt letztendlich alles 
aus dem Makefile aber je nachdem wie verzwickt das aufgebaut ist ist es 
oftmals einfacher einfach zu sehen was es macht.

Punkt 4 kann auch von Eclipse vollautomatisch ausgeführt werden, dazu 
muss Punkt 3 bereits erfolgreich laufen und es müssen einige 
Einstellungen geändert werden aufgrund der fehlerhaften 
Defaulteinstellungen des "Build-Output-Parsers" in Eclipse. Wenn der 
aber erstmal funktioniert pflückt Eclipse sich alle notwendigen 
Einstellungen von selbst, einfach indem es dem make bei der Arbeit 
zuschaut und sich genau aufschreibt welche includes und defines 
verwendet werden.

Wenn Du erstmal ein funktionierendes Projekt hast dann kannst Du ein 
neues anlegen indem Du das Projekt in Eclipse einfach duplizierst, so 
sparst Du Dir die ganzen Einstellungen erneut durchzukauen, es lohnt 
sich also das einmal zu machen, danach wird es massiv einfacher.

[Klaus F. (kfalser)]

Bernd K. schrieb:
> Punkt 4 kann auch von Eclipse vollautomatisch ausgeführt werden.

Ich mache das immer so, wie im angehängten Bild.
Im eingekringelten Bereich muss natürlich der Name der jeweiligen GCC 
Variante angegeben werden (Arm..., avr-gcc, mb-gcc).
Damit werden die System Includes automatisch gefunden.

[Bernd K. (prof7bit)]

Klaus Falser schrieb:
> Ich mache das immer so, wie im angehängten Bild.

Ja. Und im selben Bild 2 Punkte darunter ist der "Build-Output-Parser", 
da gibts eine regexp die dazu da ist alle gcc Zeilen aus dem ganzen 
Build-Output herauszuangeln. Diese Regexp muss angepasst werden daß sie 
auf irgend-was-gcc anspricht und nicht nur auf gcc. Also zum Beispiel 
.*-gcc oder (.*-)?gcc oder so ähnlich (ausprobieren), und auch ein 
Häkchen dass das für das ganze Projekt gelten soll und nicht nur pro 
einzelner Datei.

Dann kann er auch alle Defines und die Pfade ermitteln die vom Makefile 
vorgegeben werden, nicht nur die eingebauten. Danach clean und alles neu 
bauen und alle roten Wellenlinien werden verschwinden und Autocomplete 
wird ordentlich und vollständig funktionieren.

[timertick_t (Gast)]

Das Geheimnis ist gelüftet.
Die Deklarationen liegen zwar in den entsprechenden includes, der 
zugehörige Code aber liegt in Dateien denen im Verzeichnisbaum ein 
durchgestrichener Ordner vorangestellt ist. Fast alle C-Files sind somit 
vom Projekt ausgeschlossen. So weit so schlecht.
Die Dateien sind in einer (versteckten) XML-Datei namens .projects als 
'entry excluding' vermerkt. Wenn man die Einträge entfernt, ist auch der 
Code sichtbar.
Der Rest ist'n Kinderspiel. Höhö.