Eclipse: "Ausgrauen von "ausgeIFDEFtem" Code

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 ?

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.

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?

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.

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

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.

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

--

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 ?!

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?

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.

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.