Visual Studio Linux Development mit einem existenten Projekt und die Verbindung via SSH



  • Hallo liebe Community,

    ich möchte eine Spiele-Engine entwickeln und dabei neben Windows auch Linux einbeziehen.

    Da ich nun aber nur eine sehr grundlegende Ahnung von Linux basierten Systemen habe, brauche ich ein wenig Hilfe.

    Dabei habe ich zwei Fragen.

    1. Wie kann ich ein vorhandenes Projekt am geschicktesten auf Linux builden?
    Ich möchte natürlich nicht die gesamte Engine für Linux extra nochmal schreiben.

    2. Wie erstelle ich die SSH Verbindung, die Visual Studio von mir fordert?
    In der offiziellen Dokumentation wird leider (wie all zu oft bei Linux) nicht genau darauf eingegangen, sondern es wird erwartet, dass man weiß wie es funktioniert.
    Ich verwende hierbei Windows 10 x64 und habe eine VirtualBox Maschine mit LinuxMint-xfce

    Ich bin jedem der mir in dieser Sache weiterhilft zu Dank verpflichtet,
    also vielen Dank!
    --Zuzu_Typ--



  • 1. kommt darauf an, wie portabel du im voraus gedacht hast.

    2. Weißt du nicht, was du eingeben sollst?
    Benutze doch am Anfang putty. Damit kannst du dann erstmal mit der SSH spielen.

    BTW: Dein Problem hat mit C++ nichts zu tun.



  • Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C++ (alle ISO-Standards) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Zuzu_Typ schrieb:

    2. Wie erstelle ich die SSH Verbindung, die Visual Studio von mir fordert?
    In der offiziellen Dokumentation wird leider (wie all zu oft bei Linux) nicht genau darauf eingegangen, sondern es wird erwartet, dass man weiß wie es funktioniert.

    Die "offizielle Dokumentation" ist lediglich ein Blog-Beitrag, der hauptsächlich beschreibt wie man "Remote Debugging" von auf Linux laufenden
    Programmen mit Visual Studio einrichtet (mit dem praktischen Extra dass man auch von VS aus einen Rebuild auf dem Linux-System anstossen kann).

    Das ist schon ein etwas fortgeschritteneres Setup, und sicher sehr nützlich, wenn man mit einem Windows-System für Linux entwickeln möchte.
    Wenn du mit dieser Anleitung allerdings schon Probleme hast, dann solltest du dich vielleicht erstmal damit auseinandersetzen, wie du deine
    Anwendung überhaupt grundlegend auf Linux baust und ausführst (ohne diese Visual Studio-Integration).

    Ich würde grob zu folgender Vorgehensweise raten, wenn du wirklich verstehen willst, was du da im Endeffekt tust:

    Linux ist trotz GUI-Aufsatz sehr Kommandozeilen-zentriert. Setz dich am besten erstmalmal mit den Grundlagen der Linux-Shell auseinander,
    und wie du damit einfache Aufgaben erledigst: generelle Verzeichnisstruktur unter Linux, wie man durch die Verzeichnisse ("Ordner") navigiert,
    Dateien kopiert, verschiebt (umbenennt), löscht, wie man Textdateien erstellt, bearbeitet, oder wie man Programme ausführt und kleine simple
    Shell-Skripte schreibt.

    Schau dir an, wie die Compiler (z.B. GCC/Clang) unter Linux manuell über die Kommandozeile bedient werden. Wie man eine simple .c/.cpp-Datei
    kompiliert und daraus eine ausführbare Datei erzeugt. Schau dir auch die wichtigsten Kommandozeilen-Parameter für die Compiler an (z.B. -std=c++11
    um einen gewissen C++-Standard zu aktivieren, oder -O2 für eine Optimierungsstufe, -g für das einbinden von Debug-Informationen, -I<pfad>
    für zusätzliche Include-Verzeichnisse, -D<definitions-name> für zusätzliche Präprozessor-Definitionen (äquivalent zu #define im Code), etc., etc.

    Schau dir auch an, wie der Compiler mit dem Linker (z.B. ld ) zusammenarbeitet und wie man z.B. dem Linker mitteilt, dass er bestimmte Bibliotheken
    einbinden soll (.a oder .so-Dateien - letztere entsprechen unter Linux den unter Windows Bekannten DLLs). Der Compiler ruft den Linker oft selbständig
    auf, man kann Kompilieren und Linken jedoch auch manuell in zwei separaten Schritten durchführen.

    Schau dir zumindest grob an, was es mit Makefiles auf sich hat, und wie in diesen Regeln für den Aufruf von Compiler/Linker und anderen Tools
    beschrieben werden, mit denen aus verschiedenen Quellcode- und anderern Dateien ein Programm zusammengebaut wird. Diese entsprechen
    unter Linux in etwa grob den Visual Studio Projektdateien, wobei das Makefile die Projektdatei ist und der make -Befehl grob der MSBuild -Engine
    entspricht.

    Erstelle dann aber nicht selbst ein Makefile für dein Projekt, sondern schau dir besser eines der plattformübergreifenden Build-Systeme wie z.B.
    CMake an. Mit diesen kannst du dein Projekt in einer höheren Abstraktionsebene beschreiben, und diese Build-Systeme können dir dann, so z.B.
    im Fall von CMake aus dieser Projektbeschreibung entweder unter Linux ein Makefile oder eine Projektdatei z.B. für eine IDE wie Code::Blocks
    oder Eclipse, oder unter Windows eine komplette Visual Studio Solution generieren.

    Baue und teste dein Projekt dann erstmal manuell in der Kommandozeile in der Linux VM. Ich verwende da z.B. ein ähnliches Setup, wobei ich
    den Projektordner mit Quellcode und den CMake-Dateien unter VirtualBox als "Gemeinsamen Ordner" eingebunden habe, so dass ich Änderungen
    direkt unter Windows machen kann und in der VM dann einfach nur nochmal make aufrufen muss.

    Wenn du dann wirklich mal so weit bist, dass du Remote Debugging benötigst, kannst du dann mit etwas mehr Vorwissen zu dem von dir verlinkten
    Blog-Eintrag zurückkehren. Richte dazu einen SSH-Server auf der VM ein und schau dass du mit einem SSH-Client wie z.B. PuTTY zu deiner VM
    verbinden kannst. Dazu muss natürlich die VM auch via Netzwerk erreichbar sein - am unproblematischsten sollte das in VirtualBox unter
    "Netzwerk->Angeschossen an: Netzwerkbrücke" gehen. Damit hängst du die VM quasi direkt an dein lokales Netzwerk. Denk auch dran unter Linux
    den Debugger gdb und den Debug-Server gdbserver wie im Blog beschreiben zu installieren. In der im Blog erwähnten "Build Command Line" ist
    "./build" dann in deinem Fall dann entweder ein kleines von dir geschriebenes Shell-Skript, das den Buildvorgang startet, oder ich kann mir auch
    vorstellen, dass man dann dort auch statt "./build" direkt "make" hinschreiben kann, wenn man zum Starten des Build-Vorgangs ohnehin nur "make"
    aufrufen muss.

    Auch wenn ich jetzt alles nur kurz angerissen habe, hoffe ich dass dir diese Informationen weiterhelfen - und du zumindest weisst, wonach du
    als nächstes suchen solltest.

    Gruss,
    Finnegan



  • Das hört sich nach einem sehr vernünftigen Leitfaden an.
    Ich werd' mich daran versuchen.

    Herzlichen Dank und happy new year,
    --Zuzu_Typ--



  • Ich hab' das ganze zu Hause mal ausprobiert, und mein Hauptproblem war den SSH-Daemon dazu zu bekommen die Connection anzunehmen. Dazu gibt's einige Guides im Internet, wobei die oft erwähnen dass man sich das Logfile angucken soll - was da für Fehlermeldungen drinnen stehen. Dumm war bei mir bloss dass ich kein Logfile hatte -- warum auch immer. (Da ich Linux Noob bin bin ich dem ganzen nicht weiter nachgegangen.)

    Das Problem war bei mir letztendlich dass das Key-File zu viel (!) Rechte hatte. Das mag der Herr SSH nicht, und dann verweigert er. Draufgekommen bin ich nachdem ich im passenden Config-File Login mit Username + Passwort erlaubt habe. Dann mit Username + Passwort eingeloggt und so konnte ich dann die Meldungen die auch im Logfile hätten landen sollen in PuTTY sehen.

    Der Rest war super einfach. Compiler per apt-get installiert, im Studio auf "Build" geklickt, und geht. Remote-Debugging geht auch. "Einfach so".

    Wie robust das ganze ist bzw. wie es dann mit realen Projekten aussieht weiss ich nicht, trau ich mich nicht abzuschätzen. Aber zum eben mal Probieren geht das mit Visual Studio wirklich gut - das windowsseitige Setup ist trivialst. Einzig unangenehm aufgefallen ist mir dass die minimalen Build Zeiten (=ein .cpp File mit quasi nix drinnen) recht lange sind, so geschätzt 5 Sekunden waren das schon. Wird vielleicht einfach am Overhead der SSH Connection liegen. Wie es mit Projekten mit einigen hundert oder tausend Source Files (bzw. external Dependency Header Files) aussieht weiss ich nicht. Ich kann nur hoffen dass die ~5 Sekunden nur 1x pro Build und nicht 1x pro File anfallen 😉

    ps: Das ganze funktioniert sogar mit "Bash on Ubuntu on Windows". Man braucht also nichmtal ne Linux-VM 🙂
    (Man muss bloss bei "Bash on Ubuntu on Windows" ne Bash offen haben während man baut, und da drinnen vorher manuell den SSH-Daemon starten. Lässt sich aber vermutlich auch irgendwie fixen - Scheduled Task oder was auch immer.)


Anmelden zum Antworten