Visual Studio: Liste der Module auf jeder Plattform und Konfiguration zusammenstellen

8

Ich arbeite an einem riesigen C++ -Projekt, das auf viele Plattformen mit verschiedenen Konfigurationen für jede Plattform abzielt.

Aufgrund der langen Kompilierungszeit muss das gesamte Projekt auf jeder Plattform erstellt werden, um zu testen, ob eine Änderung erfolgreich kompiliert wurde.

Was ich normalerweise mache, ist die Kompilierung der einzelnen cpp-Module, die ich auf verschiedenen Kombinationen von Plattform / Konfiguration modifiziert habe. Ich möchte diesen Prozess automatisieren, entweder mit einem Skript, einer VS-Erweiterung, was auch immer, ich bin offen für die Bewertung verschiedener Optionen.

Was ich genau brauche, ist eine Liste von cpp-Dateien zu erstellen und jede Datei für jede Plattform und jede Konfiguration zu kompilieren (im Grunde alle Kombinationen des Konfigurationsmanagers durchlaufen).

Ist das möglich? Gibt es einen guten Vorschlag zur Lösung des Problems?

BEARBEITEN:

Ich bin mir bewusst, dass dies bei weitem eine perfekte Lösung ist und nur eine Teilmenge von Fehlern erkennen wird. Ich werde immer noch mit Verknüpfungsfehlern konfrontiert werden, Compiler-Fehler auf anderen cpp-Einheiten abhängig von einer modifizierten Kopfzeile und so weiter ..

Ich habe auch keine Chance, das aktuelle Build-System oder die Projektgenerierung zu ändern.

Ich bin vor allem an einer lokalen Lösung interessiert, um die Anzahl der möglichen Probleme zu reduzieren und den riesigen Bauzeitprozess zu bewältigen.

EDIT2

Wir haben ein Build-System. Dies muss als Pre-Build-Systemoptimierung für meinen persönlichen Workflow betrachtet werden.

Gründe:

Das Auslösen eines Build-System-Jobs erfordert Zeit. Es wird der letzte Schritt sein, aber statt stundenlang zu warten und vielleicht später zu entdecken, dass ein bestimmter Compiler auf einer bestimmten Plattform für eine bestimmte Konfiguration einen Fehler verursacht, wäre es viel effizienter, diese Ergebnisse so gut wie möglich vorherzusehen / p>

Aktueller manueller Workflow:

  1. Öffnen Sie jede cpp-Datei, die ich geändert habe
  2. Kompilieren Sie jede cpp-Datei als eine einzelne Einheit (das Projekt wird nicht erstellt. Auf VS Build- & gt; Kompilieren)
  3. Ändern Sie Plattform und / oder Konfiguration und führen Sie Punkt 2 erneut aus.

Dies ist der manuelle Workflow, den ich optimieren möchte.

    
Heisenbug 05.02.2017, 18:15
quelle

2 Antworten

3

Ich würde vorschlagen, dass Sie "einfach" ein Skript schreiben, um dies zu tun (zum Beispiel mit Python, das für diese Art von sehr mächtig ist)

Sie könnten:

  • Analysieren Sie die .sln-Datei, um die Liste der Konfigurationen, Plattformen ( GlobalSection(SolutionConfigurationPlatforms) entry) und Projekte ( Project entry)
  • zu extrahieren
  • Bei Bedarf können Sie jedes Projekt analysieren, um die Liste der Quelldateien zu finden (das ist einfacher als das Analysieren der .sln-Datei, da sich vcxproj-Dateien in xml befinden). Suchen Sie nach ClCompile xml-Knoten, um die Liste der .cpp-Dateien zu extrahieren.
  • Dann können Sie identifizieren, welche Projekte einige zu rekompilierende Dateien benötigen (Liste der geänderten Dateien als Skript-Eingabeparameter abrufen oder basierend auf Zeitstempelprüfung)

Zum Wiederherstellen haben Sie zwei Möglichkeiten:

  • Rufen Sie "msbuild" auf, um das gesamte Projekt (vcxproj) neu zu kompilieren (zum Beispiel msbuild project.vcxproj /p:Configuration=Debug;TargetFrameworkVersion=v3.5 )
  • Sie könnten auch eine einzelne Datei neu kompilieren ( cl simple.cpp ). Um dies zu tun, müssen Sie wissen, was die Optionen cl build sind, damit Sie die Datei genau so kompilieren wie Visual Studio. Wenn Sie zuvor einen vollständigen Build der Lösung erstellt haben (dies könnte eine Voraussetzung für das Funktionieren Ihres Skripts sein), sollten Sie in der Lage sein, das aus Visual Studio-Protokollen (innerhalb des Zielordners) zu finden. In meinen Lösungen kann ich für jedes Projekt (vcxproj-Datei) ein Build-Protokoll pro Konfiguration finden (in %OUTPUT_DIR%\lib\%libname%\%libname%.dir\%configuration%\%libname%.tlog\CL.command.1.tlog ), diese Datei meldet die genauen cl Argumente, die zum Kompilieren jeder Datei des Projekts verwendet wurden. Dann können Sie den cl -Befehl manuell aufrufen, und das sollte dazu führen, dass die Datei auf dieselbe Weise neu kompiliert wird, wie Visual Studio es tun würde.

Außerdem könnten Sie ein Projekt in Ihrer Visual Studio-Lösung hinzufügen, das dieses Skript als benutzerdefinierten Befehl auslöst.

Ein solches Skript sollte identifizieren können, welche Projekte neu erstellt und neu erstellt werden müssen.

    
jpo38 13.02.2017 11:33
quelle
2

Dies ist eine sehr gemeinsame Anforderung, sie wird niemals auf diese Weise gelöst. Was Sie vorschlagen, ist nicht völlig unmöglich, aber es ist sicherlich sehr schmerzhaft zu implementieren. Sie übersehen, was passieren sollte, wenn Sie eine .h-Datei ändern, wodurch einige CPP-Dateien neu kompiliert werden können. Und Sie denken nicht über Linkerfehler nach. Während Sie versuchen, .cpp-Dateien zu entdecken, ist das Auffinden von #include-Dateiabhängigkeiten sehr grob. Sie können sie nicht aus dem Projekt holen oder eine Datei erstellen. Kompilieren mit / showIncludes und Parsing der Build-Trace-Dateien ist, was es braucht. Nichts von der Stange afaik.

Tun Sie das nicht, Sie werden es bereuen. Verwenden Sie die Lösung, die jeder benutzt: Sie benötigen einen Build-Server. Vorzugsweise mit einer Funktion zur fortlaufenden Integration, so dass der Server den Build für alle Zielplattformen startet, sobald Sie eine Codeänderung einchecken. Viele davon können ausgewählt werden, diese Q + A spricht darüber.

    
Hans Passant 23.05.2017 12:24
quelle