Forum: Compiler & IDEs Eclipse: "Ausgrauen von "ausgeIFDEFtem" Code


von Simon H. (simi)


Lesenswert?

Hallo zusammen,

ich habe zu obigem Feature von Eclipse zwei Fragen.

Erste Frage, rein interessehalber:
Dass Eclipse in der Lage ist, in einem C/C++ File mit inkludierten 
h-Files alle #defines nachzuvollziehen und emtsprechend die durch #ifdef 
/ #ifndef ausgeblendeten Bereiche zu schattieren, leuchtet mir ein.

Wie zum Geier aber erkennt Eclipse, wenn ich z.B. im Makefile gcc mit 
einem -DUSE_MMU aufrufe, dass USE_MMU definiert ist? Das scheint nur zu 
funktionieren, wenn ein Compiliervorgang erfolgreich durchgeführt wird. 
Für mich grenzt das an Voodoo! Woher weiss Eclipse, mit welchen 
Parametern irgendein make irgendeinen Compiler das jeweilige C-File hat 
durchrattern lassen? Notabene: ich arbeite nicht mit managed source 
Projekten, sondern mit makefile-Projekten!
Kann es sein, dass Eclipse seinen Indexer über das makefile rattern 
lässt? Kaum, oder?!?

Meine zweite Frage ist nun praktischer Natur:
Wie kann ich Eclipse diese Variable wieder vergessen lassen? Wenn ich 
einmal eine Compilierung mit einer definierten Variable gemacht habe, 
kann ich das entsprechende -D... wieder rausnehmen - kompiliert wird 
dadurch wieder in der Variante ohne entsprechende Variable, die 
Schattierung bleibt aber so, als ob die Variable definiert wäre. Sprich: 
gcc vergisst (klar, muss ja, der vergisst ja alles wieder, wenn er 
fertig compiliert hat), Eclipse aber behält die Variable im Gedächtnis.

Gruäss
Simon

von Kai S. (zigzeg)


Lesenswert?

Das Eclipse Defines in Makefiles findet ist mir auch neu.
Vielleicht gibt es noch eine zweite Definition, dort wo man auch im GUI 
Defines definiert ?

von Klaus F. (kfalser)


Lesenswert?

Simon Huwyler schrieb:
> Notabene: ich arbeite nicht mit managed source
> Projekten, sondern mit makefile-Projekten!

Vielleicht arbeitest Du aber mit dem AVR Plugin?
Das Plugin wird eventuell die Defines setzen.

von Oliver (Gast)


Lesenswert?

Klaus Falser schrieb:
> Das Plugin wird eventuell die Defines setzen.

Nach meiner Erfahrung wird da aber nur -mmu=xxx ausgewertet, keine 
defines per -D. Und auch -mmu funktioniert nicht immer richtig.

Oliver

von Klaus F. (kfalser)


Lesenswert?

Oliver schrieb:
> Nach meiner Erfahrung wird da aber nur -mmu=xxx ausgewertet, keine
> defines per -D. Und auch -mmu funktioniert nicht immer richtig.

Die Eclipse hat die Möglichkeit, für den Indexer eigene Defines zu 
setzen.
Das hat mit der Kommandozeile nichts zu tun, oder meinst Du etwas 
anderes?

von Simon H. (simi)


Lesenswert?

Nein, ich arbeite nicht mit dem AVR-Plugin. Bloss Eclipse mit CDT und 
eine selber kompilierte Version einer GCC-Toolchain für ARM-eabi 
dahinter.

von Klaus F. (kfalser)


Lesenswert?

Simon Huwyler schrieb:
> Eclipse aber behält die Variable im Gedächtnis.

Eclipse holt die Variable mit 99% Sicherheit nicht aus dem Makefile.
Es gibt nun leider viele Orte wo sie herkommen kann.
Auf die Schnelle fallen mir folgende Orte ein :

- Environment des PCs
- Variable auf Workspace Ebene
  Preference -> C/C++ Build -> Build -> Build Variables
  Anklicken von "Show System Variables" zeigt was schon definiert ist
- Variable auf Projekt Ebene
  Project -> Properties -> C/C++ Build -> Build -> Build Variables
  Anklicken von "Show System Variables" zeigt was schon definiert ist
- Symbols auf Projekt Ebene
  Project -> Properties -> C/C++ General -> Path & Symbols -> Symbols

von Simon H. (simi)


Lesenswert?

Klaus Falser schrieb:
> - Symbols auf Projekt Ebene
>
>   Project -> Properties -> C/C++ General -> Path & Symbols -> Symbols

DAS IST ES! Vielen Dank!!

Da sind sogar all diejenigen Symbols, die in keinem C/H File definiert 
sind, sondern eben auf irgendeine Geissart über das makefile reinkamen, 
fett markiert.

Frage 2 ist also geklärt, jetzt bleibt nur noch die rein akademische 1. 
Frage. Ich bin nämlich absolut mit Dir einverstanden, dass Eclipse kaum 
das makefile parst, um herauszufinden, welche Variablen definiert sind.

Hmmm... obwohl.... DOCH. Ich glaube es. Ich sehe keine andere 
Möglichkeit. CDT weiss ja, dass ich ein make ausführe. Ich drücke ja auf 
den Hammerknopf. CDT kann nun selber mal nach dem makefile suchen. Und 
da muss nun einfach gcc und g++ Aufrufe suchen. Und selber die 
übergebenen Variablen auflösen.

SOOOOOO abwegig ist das ja nicht... immerhin macht es dasselbe mit den 
C-Files. Es parst sie durch und sucht nach #defines.

von Hans M. (Firma: mayer) (oe1smc) Benutzerseite


Lesenswert?

hallo Simon

ich glaube, du unterliegst da einem irrtum.
in eclispe helios wird ein #ifdef immer ausgegraut, ganz egal ob die 
bedingung zutrifft oder nicht.
es wird einfach von der der zeile mit #ifdef od #ifndef bis zum 
passenden #endif grau hinterlegt. verschachtelungen werden erkannt.

schoene gruesse
hans

--

von Oliver (Gast)


Lesenswert?

Hans Mayer schrieb:
> in eclispe helios wird ein #ifdef immer ausgegraut, ganz egal ob die
> bedingung zutrifft oder nicht.

Mit Sicherheit nicht. Ob man das einstellen kann, weiß ich nicht, aber 
Eclipse Helios stellt bei allen meinen Installationen nur die 
"aus-degef-ten" Blöcke grau hinterlegt dar, die aktiven sind weiß.

Oliver

von Oliver (Gast)


Angehängte Dateien:

Lesenswert?

Anbei ein Screenshot einer "jungfräuliche" Eclipse-CDT-Installation.

Oliver

von Kai S. (zigzeg)


Lesenswert?

Simon Huwyler schrieb:

> SOOOOOO abwegig ist das ja nicht... immerhin macht es dasselbe mit den
> C-Files. Es parst sie durch und sucht nach #defines.

Makefiles koennen fast beliebig komplex sein, mit bedingten Defines. Da 
rauszufinden, ob ein Define gesetzt ist ist nahezu unmöglich, ohne das 
Makefile zu interpretieren.

Sollte aber durch einen einfachen Test leicht rauszubekommen sein ?!

von Simon H. (simi)


Lesenswert?

Eben, diesen Test habe ich gemacht. Könnt Ihr gerne selber machen, ist 
ganz einfach:

Ein Makefile-Projekt erstellen (oder irgendeins aus der Grümpelkiste 
nehmen). Dann

#ifdef ICH_WILL_WEISS_SEIN
int x = 0;
#endif

irgendwo reinscheiben. int x=0 wird grau sein.

Dann im makefile im GCC-Aufruf ein -DICH_WILL_WEISS_SEIN hinzufügen.

Dann builden.

Tataaaaaa! int x = 0 ist weiss.

@Kai: Richtig, die können beliebig komplex sein. Präprozi-Anweisungen 
aber auch. Ich staune ja auch, aber weisst Du eine andere Erklärung, wie 
er herausfinden soll, dass ICH_WILL_WEISS_SEIN definiert ist?

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

Eclipse kann die Ausgabe des build-Vorgangs interpretieren ("scan the 
build output", Discovery Options) und damit auch die dem per 
make/Makefile an den Compiler übergebenen Parameter wie z.B. -Dxxx. 
Zudem kann es in der Ausgabe die Fehler herausfiltern ("error parser"). 
Weiterhin wird der Compiler aufgerufen um Voreinstellungen abzufragen 
(in "Compiler invocation command" mit entsprechenden Parametern). Auch 
gibt es noch einen Interpreter, der den Quellcode direkt auswertet 
(damit funktioniert #define foo, #ifdef foo, #endif innerhalb einer 
Quelldatei. Das Ganze ist nicht wirklich ausführlich aber dennoch in der 
Eclipse Dokumentation beschrieben. Mir ist allerdings ebenfalls schon 
aufgefallen, dass Eclipse per einmal per Kommandozeile eingestellte 
defines manchmal nicht vergisst, die Stelle an der dies manuell 
nachgebessert werden kann, wurde oben ja schon genannt. Falls die 
Möglichkeit besteht, statt definiert/nicht-definiert (und #ifdef/#endif) 
unterschiedliche Werte zuzuweisen (-Dwasauchimmer=1/=0 und 
#if(wasauchimmer==1)/#endif), funktioniert die Erkennung und 
Aktualisierung scheinbar besser, da es bei jedem build-Vorgang ein vom 
Ausgabescanner interpretierbares define gibt.

von Simon H. (simi)


Lesenswert?

Hm.... stimmt... errors parsen kann es ja auch.

Ja, dann kann er natürlich auch -Ds erkennen.

Und ich glaubte schon an Super-Kuh-Kräfte! :-)



Danke für den Tip mit dem ...=1 / ...=0! Das werde ich mal ausprobieren.

von GKR (Fa. Jetter) (Gast)


Lesenswert?

Update 2019:

Unter Eclipse Oxygen (4.7.3a) ...

Project -> Properties -> Path & Symbols -> Symbols
trotz dass hier die Defines gelistet waren, blieben die zugehörigen 
Codeteile ausgegraut.

Die Verwendung der Defines hängt hier auch davon ab ob der Indexer die 
Projektspezifischen Einstellungen verwendet:

Project -> Properties -> C/C++ General -> Indexer -> Enable project 
specific settings

Für ein komfortables umschalten zwischen verschiedenen Konfigurationen:

Project -> Properties -> C/C++ General > Indexer -> Build configuration 
for the indexer -> Use active Build configuration

Damit sich das nach dem Umschalten direkt auswirkt noch den Haken setzen 
bei:

Project -> Properties -> C/C++ General -> Indexer -> Build configuration 
for the indexer -> Reindex project on change of active build 
configuration

von GKR (Fa. Jetter) (Gast)


Lesenswert?

Eclipse vergisst:

Project -> Properties -> C/C++ General > Indexer -> Build configuration
for the indexer -> Use active Build configuration

Wenn in den Workspace Einstellungen etwas anderes als "Use active Build 
configuration" einstellt ist.

Daher muss dort auch auf "Use active Build configuration" umgestellt 
werden.

Window -> Prefrences ->  C/C++ > Indexer -> Build configuration
for the indexer -> Use active Build configuration

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.