Include Terror

Ich habe mehrjährige Programmiererfahrung, arbeite mit C++ und dabei vorwiegend mit VisualC++. Nur gibt es eine Sache, die mich schon seit Jahr und Tag verfolgt und mich immer wieder ärgert. Das sind die Include Anweisungen. Jedes mal wenn ich etwas selbst geschriebenes oder aus dem Netz gezogenes versuche in bestehende Projekte einzubinden knallt es kräftig.
Momentan habe ich den Fall, daß ich ein normales OpenGL Programm erweitern will. Alle OpenGL Include Dateien sind ordnungsgemäß eingebunden und das Programm läßt sich problemlos kompilieren. Füge ich dem Projekt jedoch meine selbst geschriebenen Klassen hinzu (die im Originalprojekt problemlos kompiliert werden) und include die gebrauchte Headerdatei, so gibts mal wieder enormen Ärger. In den hinzugefügten Dateien werden nochmals, die OpenGL Headerfiles eingebunden und da die windows.h nicht nochmal eingebunden werden darf, gibt es immer einen Error. Nehme ich die entsprechende Anweisung heraus, meckert der Compiler über die gl.h, da dort ein Ausdruck nicht aufgelöst werden kann, da das Makro dafür irgent wo anders steht. Wohlgemerkt die selbe Include Reihenfolge wurde vorher problemlos kompiliert, bzw. auch die Klassen liesen sich in einem anderen Projekt (Dialogfeldanwendung) problemlos verarbeiten.

Da das Problem zu speziell ist, daß ich hier eine Lösung erwarten kann, wollte ich mal fragen, ob es irgentwelche Tipps oder How-Tos zu Projekten und Includes gibt, womit man solch einem Horror entgehen kann. Irgentwie kommt so etwas immer zu kurz.

Exakt das hat mich dazu gebracht, FLTK aufzugeben und mir ein anderes GUI-Toolkit zu suchen.
Jetzt, wo ich die Alternativen gesehen habe, benutze ich doch wieder FLTK.

nun ja, wegen sowas mache ich um die includes immer noch nen #indef block drum rum, nuetzen tut es wohl nicht wirklich was, bei fremden includebibliotheken.

Was mich dabei auch immer nervt ist, dass man die Objecte per and mitteilen muss, dass die gelinkt werden muessen. Wenn ich math.h einbinde, muesste der compiler/linker doch eigentlich selber wissen, auf welche *.lib sich die include anweisung bezieht, so dass man nicht per hand nicht den -lm dahinterhaengen muss -__-

Ich persoenlich waere ja fuer die einfuehrung einer weiteren compilerdirektive, die in den header reinkommt, und dem compiler/linker sagt, welche bibliothek er einbinden soll, sofern nicht explizit was anderes in den compileroptionen drin steht.

Ich persönlich wäre dafür, daß mehr Leute Makefiles benutzen.
Ich habe ein Standardmakefile, das mir einige zum Kompilieren und Testen nützliche Funktionen bereitstellt. Das kopiere ich einfach in den Ordner eines neuen Projekts und ändere im Idealfall eine einzige Zeile, dann kann ich das Projekt per make kompilieren. Fertig.

Ja, das geht auch unter Windows. MinGW32 + MSYS installieren und fertig.


PS: Ich kann ja mal versuchen, ein generisches Makefile fertigzumachen, das ein paar Funktionen bietet etc.

Hi ihr Lieben im Coder-Forum *wink*

@Ineluki:
Ich weiss ja nit, wie du auf Herrn Gates zu sprechen bist *fg*, aber Microsoft's MSVC Compiler bietet dort eine Lösung an. zB:
[FONT=courier new]#pragma comment(lib, "opengl32")[/FONT]
Borlands Builder macht das wohl auch aber wie es bei Linux/Unix aussieht? http://www.multimediaxis.de/images/s.../1/gruebel.gif

@Jesus_666:
:A Prima Idee, das! Und wenn du einmal dabei bist, lieber Jesus... M$ hat doch da diese optimierenden Compiler freigegeben... kannst du die da auch noch mit einbinden? *liebguck*

@OdinsSpeer:
Jo, du. Geht mir auch oft so. *knuff* Generelle Lösung gibts wohl nit, denke ich. Muss man halt a bissi basteln. ;) Wichtig ist halt, dass man bei seinen eigenen Projekten ein wenig draufschaut. Faustregel sollte wohl sein: Nur die wirklich nötigen Include-Files mit reinnehmen.

Küsschen, Feenstaub.

Zitat:

---

Original geschrieben von Feenstaub
@Jesus_666:
:A Prima Idee, das! Und wenn du einmal dabei bist, lieber Jesus... M$ hat doch da diese optimierenden Compiler freigegeben... kannst du die da auch noch mit einbinden? *liebguck*

---

Wenn Microsofts Compiler GNU-Makefiles verarbeiten kann, ja. ;P Das Ding ist ja, daß man unter Windows Makefiles nur per MinGW verarbeitet kriegt (das bringt make mit) und dann schon einen guten Compiler zur Hand hat...

Aber ernsthaft: Ich unterstütze gerne Compiler/Umgebungen, die standardkonformes C++ benuzen. Sobald MSVC damit anfängt werde ich es auch berücksichtigen.

BTW, was meinst du mit "optimierender Compiler"? Alle modernen Compiler sind entweder optimierend oder nicht konkurrenzfähig.

Hier gibt's ein übermäßig kompliziertes aber vielseitiges Makefile.


Übrigens, ich habe das Problem auch wieder... Nur diesmal richtig obskur.
Mein Projekt verteilt sich auf folgende Verzeichnisse (relative Pfade):
/ - die Programmdaten für das Hauptprojekt
/FileParser - hier habe ich meinen Parser zusammengebaut und getestet, bevor ihn ihn mit dem Hauptprojekt zusammenführen wollte
/res - hier befinden sich Dateien, die im Parser includet werden

Wenn ich in /FileParser eine kleine .cpp baue, die nichts tut als den Parser zu includen, dann funktioniert das wunderbar. Wenn ich den Parser allerdings vom Hauptprojekt aus include, dann kriege ich Linkfehler, weil der Linker in den Objektdateien für alles aus /res undefinierte Referenzen bringt.
Wenn ich allerdings den Code für das Hauptprojekt nach /FileParser kopiere und dort einfach den Include oben reinpfropfe beschwert sich der Linker nicht.
Ich habe alle Dateien an den Pfad angepaßt (in den Includepfaden ../ vorangestellt bzw. entfernt), also sollte eigentlich alles überall gleich kompilieren. Tut es aber aus irgendeinem Grund nicht.

Egal, was ich mache, Programmieren mit C++ läuft letztenendes immer auf Voodoo hinaus - argh.

PS: Nach ein paar Versuchen habe ich Folgendes herausgefunden: Ich kann mein App linken, wenn ich die Quelldateien in einen anderen Ordner kopiere. Ich kann überall linken, nur nicht in dem Ordner in dem die Quelldateien erstellt werden (ein RAD-Tool erstellt sie). Selbst, wenn alle Dateien im Erstellungsordner absolut identisch sind kann ich dort nicht linken.