Wie organisiert ihr Eure C++ Projekte und Abhängigkeiten unter Windows

Hi liebe Gemeinde! Ich bin ab kommender Woche seit langem in der Situation mit C++ unter Windows (Visual Studio 2010) zu entwickeln. In den letzten Jahren waren es ausschließlich Java Projekte mit eclipse.

Da ich gerade dabei bin mich vorab schon mal ein wenig reinzufuchsen, stellt sich mir gleich die erste Frage bevor es richtig losgehen kann. Wie organisiert ihr Eure Projekte unter Windows?

Worum es mir konkret geht, bzw. wo mir einfach die Erfahrung fehlt:
Wo platziert ihr externe Abhängigkeiten (lib, dll), wie z. B. openssl, boost, poco, etc.? Legt ihr diese z. B. alle unter einen bestimmten Verzeichnis ab und verwendet dieses immer wieder? Oder legt ihr diese direkt in den Systemverzeichnissen ab? Oder oder oder?

Vielen Dank für eure Zeit!

Lila Lina schrieb:

Worum es mir konkret geht, bzw. wo mir einfach die Erfahrung fehlt:
Wo platziert ihr externe Abhängigkeiten (lib, dll), wie z. B. openssl, boost, poco, etc.? Legt ihr diese z. B. alle unter einen bestimmten Verzeichnis ab und verwendet dieses immer wieder? Oder legt ihr diese direkt in den Systemverzeichnissen ab? Oder oder oder?

Da man externe DLLs sowieso immer mitliefern muss, wenn man ein Programm gegen sie gelinkt hat und der Linker in der Regel im Programmorder sucht, macht es Sinn die DLL Datei gleich in den Programmordner zu stopfen.

Denn sonst müßte man bei Verwendung eines bestimmten Verzeichnis ja jedesmal direkt im Quellcode bei den #include "" Anweisungen auf dieses Verzeichnis verweisen und da dieses nur auf der eigenen Maschine existiert ist dies somit schlecht, wenn andere mitentwickeln sollen.

Und im Systemorder ist es deswegen schlecht, weil das nur zu Chaos führt, vor allem wenn mal ein 3rd Party Programm so ne DLL mit gleichem Namen selbst da hininstallierten sollte.
In den Systemordner gehört das, auch wenn's bequem sein mag, also nicht rein, denn das ist schlechter Stil.

It0101

Also wir haben intern in unserem Team alle eine vom Grundaufbau identische Partition. Dort findet man verschiedene Unterordner als Kategorien und in den Kategorien befinden sich die einzelnen Projektordner. Egal mit welcher IDE oder Programmiersprache sie geschrieben wurden. Projekt ist Projekt.

Für alle externen libs, wie openssl, zlib, curl, boost etc. haben wir wiederum einen eigenen Ordner. Dort kommen auch selbstentwickelte Bibliotheken rein.

Diese Ordnung hat den Vorteil, dass man sich nötigenfalls auch auf dem Rechner eines Kollegen zurechtfindet. Wichtig ist natürlich, immer regelmäßig einzuchecken und auszuchecken, damit auch alle auf dem gleichen Stand sind.

krümelkacker

Ich habe Boost 1.49 nach c:\Boost installiert und im lib-Ordner befinden sich alle möglichen (statischen) Libs einmal für MinGW64 und einmal für VC10 drin. Andere Libs haben irgendwelche anderen Plätze. Für Visual Studio habe ich entsprechende "Property Sheets" erzeugt, die man einfach "importieren" kann, um das eine oder andere relativ einfach benutzen zu können. Dem MinGW64 g++ kann man über Systemvariablen sagen, wo er nach Libs und Headerfiles suchen soll. Da trage ich mir all die Dinge ein, die ich als global installiert betrachte, so dass man nicht für jeden Kram -I oder -L benutzen muss. Das sind u.a. die Boost-Verzeichnisse, Eigen3, FFTW und SDL.

Ich musste aber auch neulich feststellen, dass die WinAPI-Header teils Compiler-spezifisch sind. Ein kleines blödes Programm, was einfach nur eine serielle Schnittstelle öffnet und mit meinem PIC32 Microcontroller redet, bekam ich nicht kompiliert, weil irgendwo ab <windows.h> auch ein Header reingeholt werden sollte, den MinGW64 logischerweise nicht mitliefert. Es handelte sich da nämlich um Microsoft's "SAL" (source annotation language). Schöne Schei*e. Bin dann mal wieder auf Visual Studio umgestiegen. das ist eh etwas unbefriedigend mit dem Hin und Her. Am besten bleibst du bei Microsofts Compiler. Das ist ja der Quasi-Standard-Compiler für Windows, mit dem das Windows SDK ja ohne Probleme laufen sollte.

Mechanics

just my 3 cents schrieb:

Denn sonst müßte man bei Verwendung eines bestimmten Verzeichnis ja jedesmal direkt im Quellcode bei den #include "" Anweisungen auf dieses Verzeichnis verweisen und da dieses nur auf der eigenen Maschine existiert ist dies somit schlecht, wenn andere mitentwickeln sollen.

WTF?

#include "../../meinLibVerzeichnis/blubber.h"

oder

#include " %PROGRAMFILES%/meinLibVerzeichnis/blubber.h"

#include "%system%/include/blubber.h"

#include "./include/blubber.h"

2 und 3 sind Murks.
1 und 4 sind okay.

Mit den DLLs wird's noch schlimmer.

Alle 4 sind Murks. Informiere doch mal über "Addition Include Directories" (Projekteinstellung), /I (Schalter von cl.exe) oder INCLUDE (Umgebungsvariable).

EinGast schrieb:

Alle 4 sind Murks. Informiere doch mal über "Addition Include Directories" (Projekteinstellung), /I (Schalter von cl.exe) oder INCLUDE (Umgebungsvariable).

Auch dann hat das immer noch nichts mit "externen DLLs" zu tun.

Hallo,

an den unprofessionellen Antworten erkennt man das hier nur ganz wenig Leute als professionelle C++ Entwickler (also für Geld) proggen.

-i schrieb:

Hallo,

an den unprofessionellen Antworten erkennt man das hier nur ganz wenig Leute als professionelle C++ Entwickler (also für Geld) proggen.

Ich glaube eher, dass viele professionelle Softwareentwickler davon keine Ahnung haben.

Ich benutze Include-paths für die Header und Libs, die innerhalb des Projektverzeichnisses liegen, sodass einfach der Projektordner kopiert werden kann. Das Ausführungsverzeichnis kriegt zusätzlich noch alle benötigten DLL's.

Das funktionierte bisher für mich, aber ich habe da deshalb auch noch nicht weiter drüber nachgedacht.

It0101

Dann scheinst du nicht sonderlich viele Bibliotheken zu benutzen. Also wenn ich jedesmal das komplete Boost, LibCurl, OpenSSL und co in jedes meiner Projektverzeichnisse kopieren würde, wäre ich längst wahnsinnig geworden...