Forum: Compiler & IDEs Truestudio/Eclipse Header Reihenfolge


von Steven (Gast)


Lesenswert?

Hallo zusammen,

Truestudio/Eclipse macht mich fertig...
(Atollic Truestudio für STM32, ARM Toolchain)

Habe gerade ein funktionierendes Projekt um CMSIS-RTX (4.8) erweitert.
Dies hat anfangs auch geklappt.

Warum auch immer habe ich dann den Debug Ordner gelöscht.

Seitdem kann er das Projekt nicht mehr bauen.

Problem ist aktuell dass der Compiler in verschiedenen (RTX) 
Header-Files die Typedefs nicht findet, welche in rt_typedef.h definiert 
sind. Problem ist dass die Header in denen die typedefs nicht erkannt 
werden den rt_typedef.h eigentlich nicht einbinden und ich diese auch 
nicht verändern mag (Da ext. Repo).

Dies ist eigentlich ein Problem über welches ich gelegentlich mal 
stolpere.

Ich bekomme es einfach nicht gebacken dass der typedef-header als erstes 
geparst(?) wird, selbst wenn ich ihn im main.c ganz oben hinsetze.
Wie kann ich die IDE dazu bewegen diesen Header zu berücksichtigen?

Die Ordner Reihenfolgen in Sourcepaths und Includes hätte ich schon 
angepasst.

Danke,
Steven

von Johannes S. (Gast)


Lesenswert?

Die Debug/Release Verzeichnisse kann man normalerweise löschen und die 
werden neu erzeugt.
Wenn der Compiler das include nicht findet muss es an den 
Projekteinstellungen für die Suchpfade liegen.

von Dr. Sommer (Gast)


Lesenswert?

Steven schrieb:
> Ich bekomme es einfach nicht gebacken dass der typedef-header als erstes
> geparst(?) wird, selbst wenn ich ihn im main.c ganz oben hinsetze.

Das ist genau richtig. Der Fehler muss also in Zeile 42 sein. Steht doch 
in der Fehlermeldung. Was die IDE parst ist übrigens unwichtig, es geht 
nur darum was der Compiler macht. Nur dessen Ausgabe (Console-Window) 
zählt.

von Steven (Gast)


Lesenswert?

In Zeile 42 der Consolenausgabe steht:

In file included from ..\Libraries\rtx\src\rt_System.c:35:0:
../Libraries/rtx/src/rt_Event.h:36:8: error: unknown type name 
'OS_RESULT'
 extern OS_RESULT rt_evt_wait (U16 wait_flags,  U16 timeout, BOOL 
and_wait);
        ^~~~~~~~~
../Libraries/rtx/src/rt_Event.h:36:31: error: unknown type name 'U16'
 extern OS_RESULT rt_evt_wait (U16 wait_flags,  U16 timeout, BOOL 
and_wait);


und im gleichen Ordner Libraries/rtx/src/ liegt auch die rt_typedef.h wo 
genau diese Dinge eben definiert sind.


Wie kann ich die Suchpfade in den Projekteinstellungen korrekt 
einstellen?

von Johannes S. (Gast)


Lesenswert?

ist der Pfad in C/C++ Build, Settings, Tab Tool Settings, C/C++ Compiler 
Directories eingetragen?

von Steven (Gast)


Lesenswert?

Johannes S. schrieb:
> ist der Pfad in C/C++ Build, Settings, Tab Tool Settings, C/C++ Compiler
> Directories eingetragen?

Ja

von Steven (Gast)


Lesenswert?

Egal,
Danke für die Mühe Leute. Gute N8

von Johannes S. (Gast)


Lesenswert?

das rt_TypeDef.h steht nach diesen Quellen
https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS/RTOS/RTX/SRC/rt_System.c
als erstes include drin, sieht das bei dir anders aus?

von Dr. Sommer (Gast)


Lesenswert?

Steven schrieb:
> ..\Libraries\rtx\src\rt_System.c:35:0:

Hier wird eine eigene .c Datei kompiliert, was in der main.c steht ist 
also komplett unerheblich.

Steven schrieb:
> Wie kann ich die Suchpfade in den Projekteinstellungen korrekt
> einstellen?

Da hier nicht steht, dass eine Datei nicht gefunden wird, bringt der 
Suchpfad auch nix.

von Steven (Gast)


Lesenswert?

Dr. Sommer schrieb:
> Hier wird eine eigene .c Datei kompiliert, was in der main.c steht ist
> also komplett unerheblich.

Irgendwie dann doch auch wieder nicht.
Ich habe dann in der main.c die rt_* Includes entfernt, jetzt baut er 
reproduzierbar durch.
1
#define osObjectsPublic
2
#include "osObjects.h"
3
#include "cmsis_os.h"
4
5
#include "rt_TypeDef.h" // Diese
6
#include "rt_Task.h"    // und diese

Danke nochmals,
Steven

von Johannes S. (Gast)


Lesenswert?

das kann nicht sein, wenn in rt_System.c ein Fehler gemeldet wird kann 
man den nicht in main.c beheben. Da musst du noch andere Sachen 
verstellt haben. Oder das ist durch bedingte Compilierung (mit ifdefs) 
in den Quellen geregelt.

von M. K. (kichi)


Lesenswert?

Wenn so etwas nach dem Löschen des Debug-/Release-Ordners passiert hilft 
meist ein Clean und Refresh.

von Vincent H. (vinci)


Lesenswert?

Eclipse selbst erzeugt auch nur makefiles. Im Fall der Fälle könnte man 
das mal studieren um sich anzusehn woran es scheitert.

von Dr. Sommer (Gast)


Lesenswert?

Steven schrieb:
> Irgendwie dann doch auch wieder nicht.
> Ich habe dann in der main.c die rt_* Includes entfernt, jetzt baut er
> reproduzierbar durch.

Hast du etwa irgendwo eine .c Datei inkludiert?!

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
Noch kein Account? Hier anmelden.