Complex wird in Visual Studio

Question

Ich habe ein paar Dinge, die ich nicht eine gute Art und Weise durchzuführen, in Visual Studio finden:

1. Pre-Build-Schritt ruft einen Code-Generator, der einige Quelldateien erzeugt, die später erstellt werden . Dies kann in begrenztem Maße gelöst werden, indem dem Projekt leere Dateien hinzugefügt werden (die später durch real erzeugte Dateien ersetzt werden), aber es funktioniert nicht, wenn ich die Namen und/oder die Anzahl der automatisch generierten Quelldateien nicht kenne. Ich kann es in GNU make unter Verwendung $(wildcard generated/*.c) lösen. Wie kann ich etwas Ähnliches mit Visual Studio machen?

2. Kann ich verhindern, dass das Pre-Build-/Post-Build-Ereignis ausgeführt wird, wenn die Dateien nicht geändert werden müssen (Verhalten)? Die aktuelle Problemumgehung besteht darin, ein Wrapper-Skript zu schreiben, das die Zeitstempel für mich überprüft, was zwar funktioniert, aber etwas unhandlich ist.

3. Wie kann man externe Bibliotheken und Header, die außerhalb von VS installiert sind, auffinden? Im Fall * nix würden sie normalerweise in den Systempfaden installiert sein oder sich unter autoconf befinden. Ich nehme an, dass ich in den Projekteinstellungen Pfade mit benutzerdefinierten Makros angeben kann, aber wo kann man diese Makros platzieren, damit sie leicht gefunden und angepasst werden können?

Nur klar zu sein, ich bin mir dessen bewusst, dass eine bessere Windows-Build-Systeme existieren (CMake, SCons), aber sie erzeugen in der Regel VS Projektdateien selbst, und ich brauche dieses Projekt in integrieren VS Build-System vorhanden, so Es ist wünschenswert, dass ich einfach nur VS-Projektdateien habe, keine generierten.

Answer 1

1. Wenn Sie Verhalten machen müssen und sind daran gewöhnt, können Sie visual studio makefile projects erstellen und sie in Ihrem Projekt.

2. Wenn Sie weniger klobig wollen, können Sie visuelle Studio macros und benutzerdefinierte Build-Ereignisse schreiben und binden Sie sie an bestimmte Build-Callbacks/Hooks.

3. Sie können etwas wie workspacewhiz ausprobieren, mit dem Sie Umgebungsvariablen für Ihr Projekt in einem Dateiformat einrichten können, das eingecheckt werden kann. Dann können Benutzer sie lokal ändern.

Answer 2

(1). Ich kenne keine einfache Antwort darauf, aber es gibt Problemumgehungen:

1a. Wenn der Inhalt generierter Dateien nicht kollidiert (dh es gibt keine gemeinsamen statischen Bezeichner usw.), können Sie dem Projekt eine einzelne Datei hinzufügen, z. B. AllGeneratedFiles.c, und Ihren Generator ändern, um eine #include "generated/file anzuhängen. c "zu dieser Datei, wenn sie generierte/file.c erzeugt.

1b. Oder Sie können ein separates Makefile-basiertes Projekt für generierte Dateien erstellen und mit nmake erstellen.

(2). Verwenden Sie eine benutzerdefinierte Erstellungsregel statt eines Post-Build-Ereignisses. Sie können eine benutzerdefinierte Erstellungsregel hinzufügen, indem Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen klicken und Benutzerdefinierte Erstellungsregeln auswählen.

(3). Es gibt keine Standardmethode, dies zu tun; Es muss pro Projekt definiert werden. Ein Ansatz besteht darin, Umgebungsvariablen zu verwenden, um externe Abhängigkeiten zu lokalisieren.Sie können diese Umgebungsvariablen dann in den Projekteigenschaften verwenden. Fügen Sie eine liesmich.txt hinzu, die die erforderlichen Tools und Bibliotheken und die entsprechenden Umgebungsvariablen beschreibt, die der Benutzer einstellen muss, und es sollte leicht genug für jeden Benutzer sein.

Answer 3

Speziell für # 3, verwende ich Eigenschaftenseiten, um 3rd-Party-Bibliothek Standorteinstellungen (einschließlich Pfade, Link-Pfade, usw.) zu bestimmen. Sie können Benutzermakros aus einem übergeordneten oder übergeordneten Eigenschaftsblatt verwenden, um den Anfangspunkt für die Bibliotheken selbst festzulegen (wenn sie sich an einem gemeinsamen Stammverzeichnis befinden) und dann einzelne Blätter für jede Bibliothek mithilfe des Basispfadmakros zu definieren. Es ist nicht automatisch, aber es ist leicht zu pflegen, und jeder Entwickler kann bei Bedarf ein anderes Wurzelverzeichnis haben (in unserer Umgebung).

Ein Nachteil dieses Ansatzes besteht darin, dass die auf diese Weise erstellten Include-Pfade nicht in den Suchpfaden für Visual Studio enthalten sind (es sei denn, Sie kopieren die Definitionen in den Einstellungen für Projekte und Verzeichnisse für VS). Ich habe mit einigen MS-Leuten auf der PDC08 darüber gesprochen, dass dies für VS2010 behoben wurde und die Schnittstelle im Allgemeinen verbessert wurde, aber keine soliden Versprechen von ihnen.

Answer 4

Ich habe dieses genaue Problem durchlaufen und ich habe es mit benutzerdefinierten Build Rules funktioniert.

Aber es war immer ein Schmerz und funktionierte schlecht. Ich verließ Visual Studio und ging mit einem Makefile-System mit Cygwin. Viel besser jetzt.

cl.exe ist der Name des VS-Compilers.

Update: Ich habe vor kurzem auf die Verwendung von CMake, die mit ihren eigenen Problemen zu tun hat, und cmake kann eine visuelle Studio-Lösung erstellen. Dies scheint gut zu funktionieren.

Answer 5

Abhängig von genau dem, was Sie versuchen, können Sie manchmal etwas Glück haben, wenn Sie einen benutzerdefinierten Build-Schritt verwenden und Ihre Abhängigkeiten richtig einstellen. Es kann hilfreich sein, den generierten Code in ein eigenes Projekt zu übertragen und dann von Ihrem Hauptprojekt abhängig zu machen.