Zu viele Konfigurationen für ein Visual Studio-Projekt vermeiden

Question

Ich portiere gerade ein großes Linux-Projekt nach Visual Studio. Das Projekt hängt von einer Reihe von Drittanbieter-Bibliotheken (Python, MPI usw.) sowie einigen internen Bibliotheken ab. Aber es kann auch ohne diese Bibliotheken oder mit nur wenigen von ihnen gebaut werden. Daher möchte ich nicht für jede mögliche Kombination eine andere Konfiguration erstellen, z. "Parallel mit Python", "Parallel ohne Python", usw. Es gibt einfach zu viele Kombinationen. Ist dies eine Situation, in der ich MSBuild verwenden könnte?

Edit: Eine Möglichkeit, die ich in Betracht gezogen habe, ist eine Reihe von .VSprops-Dateien zu erstellen, aber das ist im Wesentlichen das gleiche wie das Erstellen einer Reihe von verschiedenen Konfigurationen.

Edit: Vielleicht CMake ist mehr was ich suche? Ich würde gerne von allen CMake-Benutzern da draußen hören ...

Answer 1

Es gibt keine gute Lösung, die mir bekannt ist. Die IDE scheint eine Konfiguration für jeden Satz von Befehlszeilenargumenten zu den Werkzeugen zu erfordern. Wenn also N verschiedene Sätze von Argumenten benötigt werden - wie es klingt, ist der Fall hier - werden N verschiedene Konfigurationen benötigt. So funktioniert die IDE, so scheint es.

Leider, aber man gewinnt selten in einem Kampf gegen Visual Studio, so habe ich persönlich immer gegeben und erstellt so viele Konfigurationen wie nötig. Es ist ein Schmerz, und es ist fummelig, und ja, die IDE sollte im Idealfall einen besseren Mechanismus für die Verwaltung der Kombinationen bieten - aber es ist machbar, und es dauert nicht so lange einzurichten, wie es sich zu dieser Zeit anfühlt .

(Wie ich sie verstehe, kann .VSprops einen Teil des Schmerzes wegnehmen, indem Konfigurationskonfigurationen zwischen den Konfigurationen einfach freigegeben werden. Also werden diese winzigen Textfelder in VS nur verwendet, um die Einstellungen zwischen den Konfigurationen einzurichten . kann untersuchen sie noch wert machen Dies ist nicht etwas, was ich mich noch verwendet haben, obwohl, nur kürzlich entdeckt)

Answer 2

Wenn Sie in Visual Studio mit der rechten Maustaste auf die Lösung klicken und Configuration Manager auswählen, können Sie Build-Ziele für jede Konfiguration erstellen.

Sie können zwischen diesen Zielen mit einem Kombinationsfeld in der Symbolleiste wählen, wenn Sie die Standardeinstellungen haben.

Diese Ziele können auch bei der Verwendung von MSBuild ausgewählt werden, genau wie Sie zwischen Release und Debug wählen können.

Answer 3

Ein Ansatz könnte bedingt Ihre Bibliotheken verweisen mit dem Condition Attribut der einzelnen Baugruppen . Referenz Element (Python, MPI, usw.).

Dies könnte Ihre Bibliotheken von den Konfigurations- und Plattformeigenschaften trennen und Ihnen ermöglichen, sie standardmäßig oder unter Verwendung von MSBuild-Eigenschaften zu erstellen.

Also in Ihrem csproj:

<Reference Include="YourPythonLibrary" 
      Condition="$(BuildType) == '' Or $(BuildType) == 'TypeA'" /> 
<Reference Include="YourMpiLibrary" 
      Condition="$(BuildType) == 'TypeA' Or $(BuildType) == 'TypeB'" /> 

Das Python standardmäßig und MPI enthält nur, wenn der richtige Buildtyp eingestellt ist. Es spielt keine Rolle, wie die Konfiguration oder Plattform eingestellt ist, und Sie können die boolesche Logik an jede Bibliothek für jeden Ihrer Build-Typen anpassen.

MSBuild /p:BuildType=TypeA 
MSBuild /p:BuildType=TypeB 

Es wäre schön, irgendeine Form von bitweise Operation unter der Bedingung zu verwenden, aber ich bin nicht sicher, dass in MSBuild möglich ist?

Hinweis: Muss nicht zu einem Referenzelement, wenn es nur als Inhalt enthalten ist, wird dieser Ansatz weiterhin funktionieren.