Allgemeine Quellcodedateien bei MinGW

NES-Spieler

Ich habe folgendes Problem:
Ich habe ein paar allgemeine Quellcodedateien, die gleichermaßen für mehrere Projekte eingesetzt werden können und die man mit

#include <AllgemeineDatei.h>

statt

#include "AllgemeineDatei.h"

einbinden können soll. Um das zu realisieren, gebe ich ja dem MinGW den Pfad einfach als Parameter mit:

g++ MeinProgramm.cpp -o MeinProgramm -I"C:\WINDOWS\Desktop\AllgemeineDateien\include"

Aber wie findet er jetzt die dazugehörigen CPP-Dateien? (In diesem Beispiel würden sie sich in "C:\WINDOWS\Desktop\AllgemeineDateien\src" befinden.) Ich kann ja nicht jede einzelne allgemeine CPP-Datei als Parameter zum Kompilieren mitgeben, denn es soll ja den Nutzer meiner allgemeinen Quellcodes nicht interessieren müssen, welche Dateien im einzelnen dort liegen, solange er nur die entsprechenden Header-Dateien richtig einbaut.

darthdespotism

Der normale Weg wäre warscheinlich die ganzen cpps in eine lib (wie heißen die nochmal mit gcc-endung) zu packen und die einfach mitzulinken

NES-Spieler

Muß man die Lib-Datei (oder welche Endung sie auch immer hat) explizit mitlinken oder reicht es, dem Compiler den Pfad zu sagen? Weil, wenn man sie direkt angeben muß, ist das ja auch wieder Mist, denn dann habe ich das gleiche Problem wie oben, nur daß ich eben keine CPP-Dateien, sondern Lib-Dateien an den Compiler übergeben muß.

Ich habe mal eine Lib-Datei erstellt (mit Visual C++, weil ich auf die Schnelle nicht rausgefunden hab, wie man das mit MinGW macht), sie in den richtigen Ordner gepackt und das ganze entsprechend mit

g++ MeinProgramm.cpp -o MeinProgramm -I"C:\WINDOWS\Desktop\AllgemeineDateien\include" -L"C:\WINDOWS\Desktop\AllgemeineDateien\lib"

kompiliert, aber es gibt dabi den Linker-Fehler der undefinierten Referenz zu der in "MeinProgramm.cpp" aufgerufenen Funktion, die in "AllgemeineDatei.h" deklariert ist.

mikey

Muß man die Lib-Datei (oder welche Endung sie auch immer hat) explizit mitlinken oder reicht es, dem Compiler den Pfad zu sagen?

Ja, du musst sie explizit mitlinken, eine einfache Ordnerangabe reicht nicht. (Dateiname benötigt). Die Libraries unter GCC haben übrigens die Endung *.a

Und warum hackst du die Befehle roh in den Compiler ein? Nimm doch ne IDE, dann hast du diese ganze Quälerei nicht. (Ich kann dir mit den Befehlen nicht helfen, da keine Ahnung)

MfG mikey.

NES-Spieler

Aber das ist doch irgendwie Mist. Nehmen wir an, ich habe 20 Header-Dateien und dazu 20 CPP-Dateien. Aus diesen 20 CPP-Dateien werden dann 20 a- oder lib-Dateien gemacht. Nun habe ich noch eine Header-Datei, die die anderen 20 einbindet, so daß der Benutzer/Programmierer nur noch diese eine Header-Datei inkludieren muß. Dann kann ich ihm doch nicht zumuten, noch die 20 Binärdateien mitzulinken.
Wie läuft das denn bei den Dateien ab, die der MinGW gleich mitliefert? Da packt der doch auch automatisch das mit rein, was gebraucht wird und man muß es nirgends angeben.

P.S.: Sind a-Dateien eigentlich Compilerunabhängig? Ich meine, wenn ich mit MinGW die Binärdateien zu meinen Quellcodes erstelle und das sind keine Lib-Dateien, könnte man die dann zum Beispiel mit Visual C++ benutzen?

Und warum hackst du die Befehle roh in den Compiler ein? Nimm doch ne IDE, dann hast du diese ganze Quälerei nicht. (Ich kann dir mit den Befehlen nicht helfen, da keine Ahnung)

Eine IDE würde hier nichts ändern, da müßte man die Dateien dann ja auch mit angeben, nur daß das dann eben über ein Menü wäre.

mikey

Wie läuft das denn bei den Dateien ab, die der MinGW gleich mitliefert? Da packt der doch auch automatisch das mit rein, was gebraucht wird und man muß es nirgends angeben.

Stimmt nicht. Viele Projekt oder -API Funktionen sind in externen Libraries definiert, die du manuell dazulinken musst.

Nun habe ich noch eine Header-Datei, die die anderen 20 einbindet, so daß der Benutzer/Programmierer nur noch diese eine Header-Datei inkludieren muß. Dann kann ich ihm doch nicht zumuten, noch die 20 Binärdateien mitzulinken.

Bei 20 Libs macht das keiner mit. Zudem kompiliert man nicht für jede einzelne Klasse (bzw. Header) eine eigene Lib, sondern packt darin mehrere Klassen aufeinmal.

Eine IDE würde hier nichts ändern, da müßte man die Dateien dann ja auch mit angeben, nur daß das dann eben über ein Menü wäre.

Schonmal dran gedacht, dass du den Compilerbefehl falsch eingegeben hast? Schließlich ist das ja auch das Kernproblem. Mit einer IDE müsstest du lediglich ein Projekt anlegen, jede *.cpp Datei hinzufügen, evtl. benötigte Libs dazulinken und kompilieren. Fertig. Und dabei hast du gleich zwei Vorteile

1.) Ein schönes, komfortables Auswahlmenü,
2.) Eine lauffähige exe, ohne Kommandogefummel.

Aber bleibt ja dir überlassen, ob du nun weiterhin auf eine Antwort hoffst, oder dir mal ne IDE zulegst.

keksekekse

Ich zum Bleistift benutze nur selten eine IDE (in Zukunft vielleicht häufiger oder ich mach mir selber eine)

M.bat

@d:\borland\tcc55\bin\make -fm.mak

m.mak

COMPILER=d:\borland\tcc55\bin\bcc32
LINKER=d:\borland\tcc55\bin\ilink32

output\main.exe: output\main.obj
 @$(LINKER) /Gn/c/x/aa/Tpe -Ioutput -joutput c0w32 main, output\main,, import32 cw32
 @copy output\main.exe

output\main.obj: src\main.c
 @$(COMPILER) -c -w -noutput src\main.c

NES-Spieler

Stimmt nicht. Viele Projekt oder -API Funktionen sind in externen Libraries definiert, die du manuell dazulinken musst.

Viele, aber eben nicht alle. Wenn ich Standard-C++ benutzen will, muß ich dem Compiler nicht sagen, daß er die libstdc++.a linken muß. Und WinAPI-Funktionen gehen auch sofort. Also muß der Compiler (oder Linker) doch irgendwo zu stehen haben, daß er sich diese Dateien selbständig heraussucht. Zumal man den MinGW ja nichtmal installieren braucht. Wenn ich nur den C-Compiler haben will, dann geht das. Und wenn ich den C++-Compiler will, dann lade ich ihn herunter und packe ihn dazu, ohne daß irgendwelche Konfigurationsdateien geändert werden. Das heißt: Es muß irgendwie gehen, daß er solche Dateien automatisch findet.

Bei 20 Libs macht das keiner mit. Zudem kompiliert man nicht für jede einzelne Klasse (bzw. Header) eine eigene Lib, sondern packt darin mehrere Klassen aufeinmal.

Na gut, aber selbst das ist ein Problem. Stell Dir vor, ich habe drei Frameworks: Ein GUI-Framework, ein GDI-Framework und ein Hilfsfunktionen-Framework. Das GUI- und das GDI-Framework greifen beide gleichermaßen auf die Hilfsfunktionen zu (das heißt, ich kann diese nicht in eines der beiden Frameworks linken), aber die sind eigentlich nur für die interne Verarbeitung und nicht für den Endprogrammierer gedacht. Wenn ich nun die a-Dateien mit angeben muß, dann brauch ich zwar keine 20 Dateien, sondern erstmal nur zwei (GUI und GDI), aber das Hilfsframework müßte auch noch dazugelinkt werden, obwohl es eigentlich eine interne Sache ist. Das heißt: Wenn ich mich eines Tages dazu entschließe, das Hilfsframework fallenzulassen und die Funktionen als private Methoden in den Hauptframeworks einzubauen, würden Batch-Dateien oder Makefiles, die das Kompilieren übernehmen sollten, nicht mehr funktionieren.

Schonmal dran gedacht, dass du den Compilerbefehl falsch eingegeben hast?

In welchem Zusammenhang meinst Du das jetzt?

Schließlich ist das ja auch das Kernproblem.

Nein, das Kernproblem ist, daß ich eine Methode suche, mit der ich für a- oder lib-Dateien nur den Ordner angeben brauch und sich der Linker die benötigten Dateien dann selbst sucht, man mir aber sagt, daß das nicht geht.

Mit einer IDE müsstest du lediglich ein Projekt anlegen, jede *.cpp Datei hinzufügen, evtl. benötigte Libs dazulinken und kompilieren. Fertig.

Ich sage doch: Das würde nichts ändern: Die Libs müßten immer noch explizit dazugelinkt werden. Aber gerade das will ich ja verhindern, damit meine Batch-Datei zum Kompilieren auch noch funktioniert, wenn ich die interne Struktur des Frameworks ändere. Daher will ich dem Compiler nur sagen: "Meine Framweorks liegen alle in dem und dem Ordner. Wenn eine Funktion aus den Header-Dateien benutzt wird, such dort nach ihr und linke sie mit."

NES-Spieler schrieb:

Ich habe ein paar allgemeine Quellcodedateien, die gleichermaßen für mehrere Projekte eingesetzt werden können ...
Aber wie findet er jetzt die dazugehörigen CPP-Dateien?

Schreibe die Definition mit in die entsprechende Header-Datei. Dann brauchst Du keine "CPP" zur "H" mehr.

NES-Spieler

Ja gut, aber das wäre ja jetzt ein Umgehen des Problems. Ich habe meine Funktionsdefinitionen nie in die Header-Dateien geschrieben und möchte diese Praxis nicht ändern, bloß weil ich da jetzt auf ein kleines Linkerproblem gestoßen bin.

Hat noch jemand einen Vorschlag? Ich meine, wie ist das eigentlich mit irgendwelchen externen Bibliotheken, wie der MFC, DirectX, SDL etc.? Dort muß man doch garantiert auch nicht die Lib-Dateien explizit mitlinken oder irre ich mich da?

es gibt #pragma(lib, dateiname) aber ob das unter gcc funktioniert weiß ich nicht

mikey

es gibt #pragma(lib, dateiname) aber ob das unter gcc funktioniert weiß ich nicht

Kennt weder GCC noch MinGW, afaik nur VS.
NES-Spieler, nimm DLL's

NES-Spieler

NES-Spieler, nimm DLL's

Bitte keine Lösungen, die darauf hinauslaufen, daß am Ende etwas völlig anderes als das ursprünglich Geplante realisiert wird.
Ich meine: DLL-Dateien benutzen oder alles in die Header-Dateien packen kann doch nun wirklich nicht die Lösung sein, wenn es darum geht, allgemeine Klassen und Funktionen bereitzustellen.

Warum nicht ?

Wenn der Quellcode Deklarationen und Definitionen dieser Klassen und Funktionen enthält, dann bekommt der Linker sämtliche Informationen vom Kompiler. Ein Linkerproblem gibt es dann nicht.

Oder sollten im Quellcode die Definitionen nicht auftauchen ?

NES-Spieler

Im Quellcode schon, aber nicht in den Header-Dateien, ganz einfach deshalb, weil ich das sonst ja auch nicht mache. Normalerweise lagere ich Klassenmethoden in CPP-Dateien aus, da ich eine Klasse, wo die Funktionsdefinitionen drinstehen, ganz einfach unübersichtlich finde. Und mein Programmierstil soll eben nicht davon abhängen, welche Problemchen der Linker hat.

Eine CPP lässt sich auch mittels "#include <...>" einbinden :

(...)
#include <Funktionen.h>
#include <Funktionen.cpp> 
(...)

Das hat den gleichen Effekt, als würde sich Deklaration und Definition in einer Datei befinden.
Ein Linkerproblem gibt es dann auch nicht.

NES-Spieler

Ach Leute, kommt schon! Was sind denn das für Hackermethoden? Eine CPP-Datei mittels include einbinden.
Es muß doch irgendwie gehen, lib- (oder a-)Dateien zu einem Programm zu linken, ohne den Dateinamen anzugeben und ohne solche Tricks anzuwenden. Ich meine, was macht man denn, wenn man zum Beispiel DirectX oder SDL programmiert? Dann lädt man doch auch extra Dateien runter, aber ich glaube nicht, daß man dann die entsprechenden (zahlreichen) Binärdateien manuell dazulinken muß. Da schreibt man doch in seinen Code garantiert nur #include <SDL.h> und dann war's das, oder irre ich mich? (Genauso wie ich bei der Benutzung der iostream nicht die libstdc++ dazulinken muß.
Wenn also jemand weiß, wie die korrekte Vorgehensweise in so einem Fall ist, dann wäre ich sehr dankbar, wenn er es mir sagen würde. Ansonsten: Irgendwelche Tricks und Kniffe im Stil von #include "Quellcode.cpp" sowie Alternativen wie DLL-Dateien brauche ich nicht. Wenn das mein Ziel gewesen wäre, hätte ich auf sowas auch selber kommen können. Aber ich würde jetzt eben gern wissen, wie man es [i]richtig[/] macht.

mikey

Boah man raffst du das nicht?? Ich habe dir bereits zweimal gesagt, dass du zu linkende Libraries explizit angeben musst. Aber du akzeptierst das anscheinend nicht. Tja, und jetzt fragst du dich bestimmt, wie das SDL und Co. machen? Dazu hat dir bereits nerk und ich indirekt eine Antwort gegeben. Guck doch mal in die <SDL.h> rein, dann weist du wie's gemacht wird. Ja - du ahnst es vielleicht nicht, aber es geht mit pragma-Befehlen und DLLs. Welch Überraschung, nicht?

NES-Spieler

Ich wußte, daß Du Dich jetzt aufregen würdest.

Du hast mir zwar bereits gesagt, daß man die Dateien explizit mitlinken muß, aber das erklärt immer noch nicht, wieso der Compiler und der Linker offenbar keine Probleme haben, die Standardlibs/mitgelieferten Libs automatisch zu finden. Da ich nicht davon ausgehe, daß die Dateien in den Programmen hardcodiert sind und ich auch nirgendwo eine Datei gefunden habe, in der alle diese Dateien nochmal aufgelistet sind, so daß der Compiler unter Umständen darauf zugreifen könnte, bleibt also immer noch die Frage offen, warum man die mitgelieferten Libs nicht mitlinken muß und ob das dann nicht auch mit externen Libs geht.

ist hardcodiert