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
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.
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
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 --
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
Anbei ein Screenshot einer "jungfräuliche" Eclipse-CDT-Installation. Oliver
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.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.