Verwenden von Makefile anstelle von Lösungs-/Projektdateien unter Visual Studio (2005)

Question

Hat jemand Erfahrung mit der Verwendung von Makefiles für Visual Studio C++-Builds (unter VS 2005) im Gegensatz zur Verwendung des Projekt-/Lösungs-Setups?Für uns ist die Art und Weise, wie das Projekt/die Lösungen funktionieren, nicht intuitiv und führt zu einer Explosion der Konfiguration, wenn Sie versuchen, Builds mit bestimmten Flags zur Kompilierungszeit zu optimieren.

Unter Unix ist es ziemlich einfach, ein Makefile einzurichten, dessen Standardoptionen durch Benutzereinstellungen (oder andere Konfigurationseinstellungen) überschrieben werden.Aber solche Dinge scheinen in Visual Studio schwierig zu sein.

Beispielsweise haben wir ein Projekt, das für drei verschiedene Plattformen erstellt werden muss.Jede Plattform kann mehrere Konfigurationen haben (z. B. Debug, Release und mehrere andere).Eines meiner Ziele bei einem neu gegründeten Projekt ist es, eine Lösung zu haben, bei der alle Plattform-Builds zusammenleben können, was das Erstellen und Testen von Codeänderungen erleichtert, da Sie nicht drei verschiedene Lösungen öffnen müssen, nur um Ihren Code zu testen.Für Visual Studio sind jedoch 3 * (Anzahl der Basiskonfigurationen) Konfigurationen erforderlich.d.h.PC-Debug, X360-Debug, PS3-Debug usw.

Es scheint, dass eine Makefile-Lösung hier viel besser ist.Zusammen mit einigen grundlegenden Batchdateien oder Skripten wäre es einfach, die Konfigurationsexplosion auf ein Minimum zu beschränken und nur einen kleinen Satz Dateien für alle verschiedenen Builds zu verwalten, die wir erstellen müssen.

Allerdings habe ich keine Erfahrung mit Makefiles unter Visual Studio und würde gerne wissen, ob andere Erfahrungen oder Probleme haben, die sie teilen können.

Danke.

(Beitrag bearbeitet, um zu erwähnen, dass es sich um C++-Builds handelt)

Answer 1

Ich habe einige Vorteile von Makefiles bei großen Projekten festgestellt, die hauptsächlich mit der Vereinheitlichung des Speicherorts der Projekteinstellungen zusammenhängen.Es ist etwas einfacher, die Liste der Quelldateien, Include-Pfade, Präprozessordefinitionen usw. zu verwalten, wenn sie sich alle in einem Makefile oder einer anderen Build-Konfigurationsdatei befinden.Bei mehreren Konfigurationen bedeutet das Hinzufügen eines Include-Pfads, dass Sie sicherstellen müssen, dass Sie jede Konfiguration manuell über die umständlichen Projekteigenschaften von Visual Studio aktualisieren, was mit zunehmender Projektgröße ziemlich mühsam werden kann.

Projekte, die viele benutzerdefinierte Build-Tools verwenden, können ebenfalls einfacher zu verwalten sein, beispielsweise wenn Sie Pixel-/Vertex-Shader kompilieren müssen oder Code in anderen Sprachen ohne native VS-Unterstützung kompilieren müssen.

Sie benötigen jedoch weiterhin verschiedene Projektkonfigurationen, da Sie den Aufruf des Build-Tools für jede Konfiguration unterscheiden müssen (z. B.Übergabe verschiedener Befehlszeilenoptionen an make).

Unmittelbare Nachteile, die mir in den Sinn kommen:

• Langsamere Builds:VS ist nicht besonders schnell darin, externe Tools aufzurufen oder herauszufinden, ob überhaupt ein Projekt erstellt werden muss.
• Umständliche Abhängigkeiten zwischen Projekten:Es ist umständlich, es so einzurichten, dass ein Abhängigkeitsempfänger die Erstellung des Basisprojekts veranlasst, und es ist noch umständlicher, sicherzustellen, dass sie in der richtigen Reihenfolge erstellt werden.Ich hatte einige Erfolge dabei, SCons dazu zu bewegen, aber es ist immer eine Herausforderung, es gut hinzubekommen.
• Verlust einiger nützlicher IDE-Funktionen:Bearbeiten und weiterhin der Hauptdarsteller sein!

Kurz gesagt: Sie verbringen weniger Zeit damit, Ihre Projektkonfigurationen zu verwalten, sondern haben mehr Zeit damit, Visual Studio dazu zu bringen, ordnungsgemäß damit zu arbeiten.

Answer 2

Visual Studio wird darauf aufgebaut MSBuild Konfigurationsdateien.Sie können *proj- und *sln-Dateien als Makefiles betrachten.Sie ermöglichen Ihnen, den Build-Prozess vollständig anzupassen.

Answer 3

Obwohl es technisch möglich ist, ist es in Visual Studio keine sehr benutzerfreundliche Lösung.Es wird die ganze Zeit gegen dich kämpfen.

Ich empfehle Ihnen, einen Blick darauf zu werfen NAnt.Es ist ein sehr robustes Build-System, mit dem Sie im Grunde alles tun können, was Sie tun müssen.

Unser NAnt-Skript führt dies bei jedem Build aus:

1. Migrieren Sie die Datenbank auf die neueste Version
2. Generieren Sie C#-Entitäten aus der Datenbank
3. Kompilieren Sie jedes Projekt in unserer „Master“-Lösung
4. Führen Sie alle Unit-Tests durch
5. Führen Sie alle Integrationstests aus

Darüber hinaus nutzt unser Build-Server dies und fügt eine weitere Aufgabe hinzu, nämlich die Erstellung der Sandcastle-Dokumentation.

Wenn Sie XML nicht mögen, können Sie auch einen Blick darauf werfen Rechen (Rubin), Bake/BooBuildSystem (Boo), oder Psake (Power Shell)

Answer 4

Sie können Nant verwenden, um die Projekte einzeln zu erstellen, wodurch die Lösung ersetzt wird und Sie über eine Codierungslösung und keine Build-Lösungen verfügen.

Beachten Sie, dass es sich bei den Lösungs- und CSPROJ-Dateien ab VS 2005 um MSBuild-Skripte handelt.Wenn Sie sich also mit msbuild vertraut machen, können Sie möglicherweise die vorhandenen Dateien verwenden, um vs einfacher zu gestalten und Ihre Bereitstellung zu vereinfachen.

Answer 5

Wir haben eine ähnliche Einrichtung wie die, die Sie beschreiben.Wir unterstützen mindestens 3 verschiedene Plattformen, also haben wir das gefunden CMake um die verschiedenen Visual Studio-Lösungen zu verwalten.Die Einrichtung kann etwas mühsam sein, aber es läuft im Wesentlichen darauf hinaus, die Dokumentation und ein paar Tutorials zu lesen.Sie sollten praktisch alles tun können, was Sie tun können, indem Sie zu den Eigenschaften der Projekte und der Lösung gehen.Ich bin mir nicht sicher, ob alle drei Plattform-Builds in derselben Lösung zusammenleben können, aber Sie können sie verwenden Tempomat um sich um Ihre Builds zu kümmern und Ihre Testskripte so oft wie nötig auszuführen.