Gemäß mehrere Empfehlungen probiere ich jetzt mal VSCode statt VS, aber ich komme noch gar nicht zum Editieren, weil ich keinen Build hinkriege.
- Das Internet sagt, ich müsste in tasks.json Umgebungsvariablen ansprechen können, und mein Build-Task müsste die Standard-Variablen aus der Benutzerumgebung erben. Aber weder $env.ComSpec, $env:ComSpec, noch ${env:ComSpec} werden aufgelöst.
- Tasks vom Typ shell starten standardmäßig in PowerShell. Ich hasse PowerShell aus mindestens zwei schwerwiegenden Gründen. Zumindest funktioniert
Code: Alles auswählen
"options": {
"shell": {
"executable": "cmd",
"args": ["/C"]
}
},
- Nun habe ich den Build mit Ach und Krach am Laufen, aber ich finde keinen ProblemMatcher, der die Zeilen der Ausgabe auf Warnungen und Fehler parsen kann. Visual Studio öffnet zumindest via Doppelklick die Datei & Zeile, aber VSCode stellt sich total quer …
Edit: Doch, VS Code kann sehr wohl Dateinamen erkennen und öffnen! Das hier geht:
X:\foo\bar.c(123,45): error blah
Das hier nicht:
X:\foo ooh\bar.c(123,45): error blah
… also sind Leerzeichen das Problem? Nagut; kann man dem armen VSCode nicht verübeln, dass es nicht ohne Anführungszeichen geht …
"X:\foo ooh\bar.c"(123,45): error blah
… geht nicht. NEEEEEEEIN
Mal im Ernst an die, die damit geübt sind: Habe ich was versemmelt, oder geht sowas Fundamentales
wirklich nicht?!
Edit 2: Defining a multiline problem matcher
Geil! Das ist genau, womit ich den Abend verbringen wollte!
Edit 3: Holy fucking shit … jetzt kriege ich meine Fehler beim Kompilieren angezeigt,
aber sie verschwinden nie wieder?!
Dieses Bug-Ticket mit extrem desillusionierten Teilnehmern behauptet, dass VSCode halt eine sehr besondere Vorstellung von Code-Fehlern hat. Die werden durch Extensions angelegt,
und Extensions müssen sie auch wieder löschen. Wenn mein Build-Skript nun beim Kompilieren Fehler meldet, muss mein Build-Skript sie auch wieder löschen, sobald ich sie korrigiert habe. WTF
Also geht so etwas wie
ein Skript ausführen, um Code zu kompilieren überhaupt nicht mit VSCode, sondern man muss ein Hintergrund-Task einrichten, das als ständiger Linter dient, und VSCode nutzt das dann, um eine Liste von Problemen aufzubauen und automatisch zu bereinigen?! Verstehe ich das richtig?! Wie geht man dann da Linker-Probleme an, die keiner Datei gehören, die in der IDE geöffnet sein kann?!
An dieser Stelle sollte ich mir wohl die C++ Extension ziehen und ein Projekt nach Microsofts Vorstellungen aufsetzen nur um zu verstehen, wie Microsoft sich vorstellt, wie ein C++-Build-Vorgang in VSCode funktionieren sollte und was für Ausgaben der macht und wie er mit Build-Problemen umgeht.
„you can’t just … compile code“
Dafür hatte ich sehr gute Unterhaltung:
every project has that one thing that makes sense to everyone except the developers. this is vscode's.
How come this is still an issue after 2 and a half years?
This piece of software carries the "Microsoft" trademarked brand. Surely there must be someone who can make an executive decision.
It is frankly absurd this hasn't been resolved yet
