Der build-log, mit dem Visual Studio die Konsole zumüllt, ist eine Zumutung. Wer schonmal wissen wollte, woher eine Header-Datei includiert wurde, die eine bestimmte Warnung verursacht, dann auf die grandiose Idee kam, mit „/showIncludes“ zu compilieren, den Build-Output als 50MB große Textdatei zu speichern, und dann in den „Including File“-Zeilen händisch (!) die Einrückung nachzuzählen (was besoders viel Spaß macht, wenn mehrere Projekte gebaut werden, und die Ausgaben der einzelnen Projekte „verwoben“ sind), hat sich vielleicht auch schon gefragt, 1. in welchem Jahrtausend das ganze entwickelt wurde, und 2. ob es da nichts vernünftigeres gibt.
Die Antwort auf Frage 1: Im vorigen.
Die Antwort auf Frage 2: Ja, Java
Die weniger polemische Antwort auf Frage 2: Naja… man könnte sich ein Tool basteln, das das ganze auseinanderpflückt.
Der BuildOutputViewer (ich hab’s nicht so mit kreativen Namen :rolleyes: ) liegt unter GitHub - javagl/BuildOutputViewer: A small utility to view and analyze the build output of Visual Studio und bietet ein paar Funktionen, die praktisch sein können, wenn man einen Build Output analysieren muss:
[ul]
[li]Er sortiert die Ausgaben mehrerer Projekte, und erlaubt es, sie als einzelne Dateien abzuspeichern
[/li][li]Man bekommt eine Übersicht, welches Projekt wie viele Compiler Warnings, Compiler Errors, Linker Warnings und Linker Errors verursacht hat
[/li][li]Die Warnings und Errors werden in Tabellen aufgelistet. Ein Klick auf die Warning/Errors erstellt (wenn „/showIncludes“ verwendet wurde) Baumansichten. Der erste Baum zeigt an, welche Dateien die Datei includiert. Der zweite Baum zeigt an, welche Dateien die Datei includieren (und die „Blätter“, so dass man die „schuldigen“ Dateien in seinem eigenen Projekt leicht(er) finden kann).
[/li][li]Schmankerl, wie dass man die Messages rechtsklicken kann, und dann die Datei oder den enthaltenden Ordner öffnen kann, sind auch dabei
[/li][li]Ein Rechtsklick auf eine Fehlermeldung erlaubt es auch, direkt die MSDN-Doku für den jeweiligen Fehlercode anzubrowsen
[/li][/ul]
(Für letzteres habe ich ein kleines Tool gebastelt, das die MSDN-Seiten crawlt, um das Mapping zwischen Fehlercodes und Links zu erstellen :rolleyes: )
Das ganze ist recht schnell runtergeschrieben, und wurde nur mit einer knappen Handvoll Build-Outputs getestet. Vieles ist sicher noch nicht abgedeckt (oder funktioniert schlicht nicht) - z.B. hatte ich bisher noch keine „Linker Warnings“, d.h. die werden noch nicht gefunden und verarbeitet :o Und auch sonst könnte man sich ungefähr 1000 Sachen vorstellen, wie man das „besser“ machen könnte. Der Support unter support@microsoft.com nimmt da Vorschläge sicher gerne entgegen. Aber wenn sie hier gepostet werden, schau’ ich vielleicht auch noch mal drauf 