makefile

HumeSikkins

schreibe noch ein header und cpp

Genau das habe ich gemacht. Habe jetzt dirstream.h, dirstreamw32.h und dirstreamw32.cpp.

in normal fall includet sie die postfix header

Genau. dirstream.h macht sowas:

#ifdef HAT_POSIX_KRAM
#include <dirent.h>
#include <sys/stat.h>
#else
#include "dirstreamw32.h"
#endif

die cpp datei beinhaltet deinen code

Richtig. Die dirstreamw32.cpp beinhaltet die Definitonen der Funktionen wir opendir, readdir usw.

dann arbeites du mit den gleichen header und das makefile ist immer gleich

So. Und hier kann ich dir nicht mehr folgen. Ich arbeite in der tat immer mit dem gleichen Header. User müssen immer nur dirstream.h inkludieren. Das makefile kann meiner Meinung nach aber nicht gleich bleiben, da es unter Win98 noch die dirstreamw32.cpp berücksichtigen muss.

Was übersehe ich?

Gerard

dirstreamw32.cpp

#ifdef WIN32
//dein code
#else
//nix
#endif

auch unter unix wird dann die dirstream32.cpp gelinkt, blos sie ist leer

HumeSikkins

Oha. So einfach kann es sein
Danke fein.

rüdiger

und wenn jemand standard-c++ nehmen muß, um das gewurstele los zu werden. das makefile ist erstmal angemessen, weils unerhört einfach zu benutzen.

ja klar, zum testen des Projekts etc. ist das natürlich gut, ich schreib mir am Anfang des Projekts auch idr. erst eine Makefile per Hand (vorallem da ich automake nicht mag)

das widerspricht eigentlich meinen vorstellungen von nem einfacen makefile. gehen tut das. aber ibts keinen anderen weg? für was brauchste das denn?

jo, einfach ist das nicht mehr aber nötig in der Praxis und dafür nimmt man ja auch eigentlich ein configure Script aber langsam geht die Mode dahin, dass man alles von Make bearbeiten lässt, ist eh viel praktischer.

wobei in Humes Situation eh kein autoconf noch Makefile Tricks mit uname helfen, da Windows nicht POSIX kompatibel ist und man auch nicht vom User erwarten kann, dass der Cygwin oä. installiert hat

volkard

[ Dieser Beitrag wurde am 07.05.2003 um 04:10 Uhr von volkard editiert. ]

HumeSikkins

@volkard
Nur um noch mal sicher zu gehen: Du hast nichts dagegen, wenn man dein makefile nahezu 1:1 übernimmt? Ist nämlich genau das was ich gerade brauche.

volkard

Original erstellt von HumeSikkins:
@volkard
Nur um noch mal sicher zu gehen: Du hast nichts dagegen, wenn man dein makefile nahezu 1:1 übernimmt? Ist nämlich genau das was ich gerade brauche.

nix dagegen. ich habs doch nur aus der hilfe von make zusammenkopiert.

aber wenn du mal was rausfundest, wie man die compilezeiten senken kann (mingw hab ich), dann sag bescheid. precompiled headers sind wohl nur angekündigt aber nicht verfügbar.

HumeSikkins

aber wenn du mal was rausfundest, wie man die compilezeiten senken kann (mingw hab ich), dann sag bescheid.

Oh. Mit dem Problem quäle ich mich auch gerade rum. Sowohl mit dem mingw, als auch mit dem gcc 3.2.2. Mit dem gcc 2.95 hatte ich wenigstens noch das Gefühl das es langsam voran geht. Jetzt ist aber nicht mal mehr schleichend das richtige Wort

volkard

Original erstellt von HumeSikkins:
[quote]Sowohl mit dem mingw, als auch mit dem gcc 3.2.2. Mit dem gcc 2.95 hatte ich wenigstens noch das Gefühl das es langsam voran geht. Jetzt ist aber nicht mal mehr schleichend das richtige Wort

hab jetzt mingw mit dem gcc 3.2.3 drin. der scheint deutlich flotter als der mingw mit dem gcc 3.2.

rüdiger

ich hätte es fast vergessen, aber ich pack den Thread mal in die FAQ

Der Link (von nman) zum GNU make-Handbuch funktioniert nicht. (Bitte korrigieren.)

Schlitzauge

Salve,

bei all dem bisher angebotenen Make-Files blicke ich jetzt nicht mehr durch.
Welches Makefile ist denn nun das Ultimative?

Eines der hier angebotenen oder dieses hier:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-88418.html

Dazu auch gleich noch ein paar Fragen:

1.)
Was bewirkt "TARGET := ./program "?

2.) Gibt es bei "CXXFLAGS := " eine Reihenfolge der Parameter einzuhalten?

3.) Bei "LIBS := " sollen wohl die zusätzlich zu includierenden Libs eingebunden werden, z.B., wenn man die SDL-Libs verwenden möchte?

4.) Ist es ratsam bei Libs standardmäßig immer alle Libs anzugeben, die man hat oder sollte man nur die angeben, welche man auch wirklich benötigt.
Es wäre nämlich klasse, wenn man alle möglichen Libs eintragen könnte und trotzdem am Ende vom Compiler nur die genommen werden, welche auch wirklich nur gebraucht werden. Und gibt bei "LIBS := " nur Libs (.lib) oder auch Header-Dateien (.h) und DLL´s an? Wenn nein, wie kann man im Makefile noch die Header-Dateien und DLL´s, sofern man welche hat vermerken?

Ich danke vielmals im Voraus!

Gruß

Schlitzauge

volkard

Schlitzauge schrieb:

bei all dem bisher angebotenen Make-Files blicke ich jetzt nicht mehr durch.
Welches Makefile ist denn nun das Ultimative?

Meins natürlich.

Eines der hier angebotenen oder dieses hier:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-88418.html

Die sind eigentlich alle das selbe. Ein paar Trick oder persönliche Vorlieben hie und da. Im Zweifel nimm das neueste, also das im anderen Thread.

1.)
Was bewirkt "TARGET := ./program "?

Name der ausführbaren Datei, die erstellt wird.

2.) Gibt es bei "CXXFLAGS := " eine Reihenfolge der Parameter einzuhalten?

Nein.

3.) Bei "LIBS := " sollen wohl die zusätzlich zu includierenden Libs eingebunden werden, z.B., wenn man die SDL-Libs verwenden möchte?

Ja.

4.) Ist es ratsam bei Libs standardmäßig immer alle Libs anzugeben, die man hat oder sollte man nur die angeben, welche man auch wirklich benötigt.
Es wäre nämlich klasse, wenn man alle möglichen Libs eintragen könnte und trotzdem am Ende vom Compiler nur die genommen werden, welche auch wirklich nur gebraucht werden. Und gibt bei "LIBS := " nur Libs (.lib) oder auch Header-Dateien (.h) und DLL´s an? Wenn nein, wie kann man im Makefile noch die Header-Dateien und DLL´s, sofern man welche hat vermerken?

Alle libs geht auch. Manchmal aber kann eine lib zu größerer ausführbarerer Datei führen, weshalb ich sparsam wäre. Die dll wird normalerweise von der lib benutzt, brauchst dich nicht drum zu kümmern. Zusätzliche Header-Verzeichnisse kannsz Du AFAIR mit -I in den CXXFLAGS noch dazumachen.

Benutze lieber die Autotools, mit Make endet das recht schnell in einem mittelgroßen Gefrickel. Insbesondere ist dank configure der Build-Ordner flexibel auswählbar, so dass man seinen Source-Tree nie mit Dateien zumüllen muss, oder Schreibrechte darin benötigt.

Der Mehraufwand ist nur marginal, dafür ist der Komfortgewinn nicht aufzuwiegen.

Schlitzauge

Meins natürlich.

Welches von den vielen?

Könnte man in Zukunft btw. zu den bisherigen, den Einsatzzweck dazuschreiben? Ich meine ja nur, damit auch Neulinge besser verstehen, wann welches Makefile denn am besten für welchen Fall ist.

Zitat:

Eines der hier angebotenen oder dieses hier:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-88418.html

Die sind eigentlich alle das selbe. Ein paar Trick oder persönliche Vorlieben hie und da. Im Zweifel nimm das neueste, also das im anderen Thread.

Hmm??? Was nun, Deines, ein anderes oder das im Nachbarthread, wobei das eigentlich ein Thread aus der FAQ ist?

Zitat:

1.)
Was bewirkt "TARGET := ./program "?

Name der ausführbaren Datei, die erstellt wird.

Das habe ich soweit schon vernommen. Ich meinte aber eher das "./program".
Woher nimmt denn dieser String die nötige Information?

Zitat:

3.) Bei "LIBS := " sollen wohl die zusätzlich zu includierenden Libs eingebunden werden, z.B., wenn man die SDL-Libs verwenden möchte?

Ja.

Muss man immer direkt die Lib-Dateien angeben, also *.lib? Oder reicht es, wenn man ein Verzeichnis mit LIB-Dateien angibt?
Und, was muss ich bei "LIBS := " machen, um mehrere LIB-/LIB-Verzeichnisse anzugeben, mit Komma trennen?

Die dll wird normalerweise von der lib benutzt, brauchst dich nicht drum zu kümmern.

Ja schon. Ich meinte aber, wenn ich eine separate DLL-Datei habe.
Wo muss ich da was einstellen, damit diese mit beim Compilieren/Linken (was denn nun?) einbezogen wird, jeweils statisch, als auch dynamisch?

Zusätzliche Header-Verzeichnisse kannsz Du AFAIR mit -I in den CXXFLAGS noch dazumachen.

Wie genau? Z.B. "-I Header1.h Header2.h, Header_n.h ..." oder anders?
Und wie wird das dann bei IDE´s gehandhabt? Ich meine, dort brauch man sich nicht wirklich um das Hinzufügen von *.h-Dateien zu kümmern. Einfaches "#include <blabla.h>" im Quelltext reicht. Kann es sein, dass es einfacher ist *.h-Dateien über die PATH-Variable global zur Verfügung zu stellen, sodass es nur noch ausreicht im Quelltext die erforderlichen Header-Dateien einzubinden?

Benutze lieber die Autotools, mit Make endet das recht schnell in einem mittelgroßen Gefrickel. Insbesondere ist dank configure der Build-Ordner flexibel auswählbar, so dass man seinen Source-Tree nie mit Dateien zumüllen muss, oder Schreibrechte darin benötigt.

Kenne mich leider damit nicht aus. Das mit den Makefiles klingt für mich interessant, weil ich dann weiß, wo ich was einsetzen muss, für den und den Einsatzzweck.

--------------------------------------------------------

5.)
Mal noch eine Zusatzfrage.
Ich verwende Code::Blocks, sowie Eclipse in Verbindung mit MinGW/MSYS.
Macht es sinn, hier eigene Makefiles (eines der obigen bzw. des Nachbarthreads aus der FAQ) einzusetzen? Wenn ja, wo muss man in Code:Blocks z.B. was angeben, um die eigene Make-File mit einzubinden (Compiler/Linker/???)?

Ich danke nochmals vielmals im Voraus!!

Gruß

Schlitzauge

byto

Sieht ja wild aus. Da lob ich mir Ant und Maven2.

byto schrieb:

Sieht ja wild aus. Da lob ich mir Ant und Maven2.

ist normal, makefiles sind relikte aus der programmierer-steinzeit, die einfach nicht totzukriegen sind.

an der Länge der install scripts und makefiles kann man vor allem sehen, wie es mit der Portabilität zwischen den Systemen wirklich bestellt ist.

dabei meine ich jetzt nicht die makefiles, um die es hier geht, sondern allgemein - ein neulich von mir installiertes kleines source-Paket hatte beispielsweise ein über 15000 Zeilen langes configure Skript - das configure Skript beanspruchte über 40% des Platzes des (komprimierten) source Pakets.

byto

Ich nehme Maven2 fürs Build und Dependancy Management meiner Projekte. Auf Knopfdruck spuckt das Build Tool plattformunabhängige Builds wahlweise für die Test, QS oder Prod Umgebung aus. Natürlich werden zuvor alle Unit- und Integrationstests automatisiert geprüft.
Das funktioniert alles mit wenigen Zeilen Konfiguration.