Travailler sur un projet distant avec Eclipse via SSH

J'ai les boîtes suivantes:

1. Une box Windows avec Eclipse CDT,
2. Une box Linux, accessible pour moi uniquement via SSH.

Le compilateur et le matériel requis pour créer et exécuter mon projet sont uniquement sur la machine B.

Je voudrais travailler "de manière transparente" à partir d'une boîte Windows sur ce projet en utilisant Eclipse CDT et être capable de construire, exécuter et déboguer le projet à distance à partir de l'EDI.

Comment configurer cela:

• Le bâtiment fonctionnera? Des solutions plus simples que d'écrire un fichier makefile local qui ferait rsyncle projet puis d'appeler un makefile distant pour lancer la construction réelle? La version gérée d'Eclipse a-t-elle une fonctionnalité pour cela?
• Le débogage fonctionnera?
• De préférence, l'indexation du code Eclipse CDT fonctionnera? Dois-je copier tous les fichiers d'en-tête requis de la machine B vers la machine A et les ajouter pour inclure le chemin manuellement?

Essayez l' explorateur de système distant (RSE). C'est un ensemble de plug-ins pour faire exactement ce que vous voulez.

RSE est peut-être déjà inclus dans votre installation actuelle d'Eclipse. Pour archiver Eclipse Indigo, accédez à Fenêtre > Ouvrir la perspective > Autre ... et choisissez Explorateur de système distant dans la boîte de dialogue Ouvrir la perspective pour ouvrir la perspective RSE.

Pour créer un projet distant SSH à partir de la perspective RSE dans Eclipse:

1. Définissez une nouvelle connexion et choisissez SSH uniquement dans l'écran Sélectionner le type de système distant de la boîte de dialogue Nouvelle connexion.
2. Entrez les informations de connexion puis choisissez Terminer.
3. Connectez-vous au nouvel hôte. (Suppose que les clés SSH sont déjà configurées.)
4. Une fois connecté, explorez les fichiers Sftp de l'hôte , choisissez un dossier et sélectionnez Créer un projet distant dans le menu contextuel de l'élément. (Attendez que le projet distant soit créé.)

Si cela est fait correctement, il devrait maintenant y avoir un nouveau projet distant accessible à partir de l'Explorateur de projets et d'autres perspectives dans eclipse. Une fois la connexion SSH correctement configurée, les mots de passe peuvent devenir une partie facultative du processus d'authentification SSH normal. Un projet distant avec Eclipse via SSH est maintenant créé.

Le moyen le plus simple serait d'exécuter Eclipse CDT sur la Linux Box et d'utiliser soit X11-Forwarding, soit un logiciel de bureau à distance tel que VNC.

Ceci, bien sûr, n'est possible que lorsque vous Eclipse est présent sur la box Linux et que votre connexion réseau à la box est suffisamment rapide.

L'avantage est que, étant donné que tout est local, vous n'aurez pas de problèmes de synchronisation et vous ne rencontrez pas de problèmes multi-plateformes gênants.

Si vous n'avez pas d'éclipse sur la boîte, vous pourriez penser à partager votre répertoire de travail Linux via SMB (ou SSHFS) et y accéder depuis votre machine Windows, mais cela nécessiterait une certaine configuration.

Les deux seraient mieux que d'avoir deux exemplaires, surtout quand c'est multiplateforme.

Je suis moi-même (ou j'étais) au même endroit, FWIW j'ai fini par vérifier un partage samba sur l'hôte Linux et éditer ce partage localement sur la machine Windows avec notepad ++, puis j'ai compilé sur la machine Linux via PuTTY. (Nous n'avions pas le droit de mettre à jour les versions dix ans des éditeurs sur l'hôte Linux et il n'avait pas Java, j'ai donc abandonné le transfert X11)

Maintenant ... J'exécute Linux moderne dans une VM sur mon hôte Windows, j'ajoute tous les outils que je veux (par exemple CDT) à la VM, puis j'exécute et je construis une prison chroot qui ressemble étroitement au RTE.

C'est une solution maladroite mais j'ai pensé que je la jetterais dans le mix.

Ma solution est similaire à celle de SAMBA sauf en utilisant sshfs. Montez mon serveur distant avec sshfs, ouvrez mon projet makefile sur la machine distante. Allez de là.

Il semble que je puisse également exécuter une interface graphique vers mercurial de cette façon.

Construire mon code distant est aussi simple que: ssh address remote_make_command

Je cherche cependant un moyen décent de déboguer. Peut-être via gdbserver?

J'ai eu le même problème il y a 2 ans et je l'ai résolu de la manière suivante:

1) Je construis mes projets avec des makefiles, non gérés par eclipse 2) J'utilise une connexion SAMBA pour éditer les fichiers dans Eclipse 3) Construire le projet: Eclipse appelle un make "local" avec un makefile qui ouvre une connexion SSH au Linux Hôte. Sur la ligne de commande SSH, vous pouvez donner des paramètres qui sont exécutés sur l'hôte Linux. J'utilise pour ce paramètre un script shell makeit.sh qui appelle le "vrai" make sur l'hôte linux. Les différentes cibles pour la construction que vous pouvez donner aussi par les paramètres du makefile local -> makeit.sh -> makefile sur l'hôte linux.

J'ai essayé ssh -Xmais c'était insupportablement lent.

J'ai également essayé RSE, mais cela ne prenait même pas en charge la construction du projet avec un Makefile (on me dit que cela a changé depuis que j'ai publié ma réponse , mais je n'ai pas essayé cela)

J'ai lu que NX est plus rapide que le transfert X11, mais je n'ai pas pu le faire fonctionner.

Enfin, j'ai découvert que mon serveur prend en charge X2Go (le lien contient des instructions d'installation si le vôtre ne le fait pas). Maintenant, je n'avais plus qu'à:

• télécharger et décompresser Eclipse sur le serveur,
• installer X2Go sur ma machine locale ( sudo apt-get install x2goclientsur Ubuntu),
• configurer la connexion (hôte, connexion automatique avec la clé ssh, choisir d'exécuter Eclipse).

Tout est comme si je travaillais sur une machine locale, y compris la construction, le débogage et l'indexation de code. Et il n'y a pas de retard notable.

Dans ce cas, vous pouvez utiliser ptp eclipse https://eclipse.org/ptp/ pour la navigation et la construction des sources.

Vous pouvez utiliser ce pluging pour déboguer votre application

http://marketplace.eclipse.org/content/direct-remote-c-debugging

Cette réponse ne s'applique actuellement qu'à l'utilisation de deux ordinateurs Linux [ou fonctionne peut-être aussi sur Mac? - non testé sur Mac] (synchronisation de l'un à l'autre) car j'ai écrit ce script de synchronisation en bash. C'est simplement une enveloppe autourgitCependant, , alors n'hésitez pas à le prendre et à le convertir en une solution Python multiplateforme ou quelque chose si vous le souhaitez.

Cela ne répond pas directement à la question du PO, mais il est si proche que je vous garantis que cela répondra à la question de beaucoup d'autres personnes qui atterrissent sur cette page (la mienne incluse, en fait, car je suis venu ici en premier avant écrire ma propre solution), donc je je le publie ici de toute façon.

Je veux:

1. développer du code à l'aide d'un puissant IDE comme Eclipse sur un ordinateur Linux léger, puis
2. construire ce code via ssh sur un ordinateur Linux différent et plus puissant (à partir de la ligne de commande, PAS depuis Eclipse)

Appelons le premier ordinateur sur lequel j'écris le code "PC1" (Personal Computer 1), et le 2ème ordinateur sur lequel je construis le code "PC2". J'ai besoin d'un outil pour synchroniser facilement de PC1 à PC2. J'ai essayé rsync, mais c'était incroyablement lent pour les gros dépôts et prenait des tonnes de bande passante et de données.

Alors, comment faire? Quel workflow dois-je utiliser? Si vous avez également cette question, voici le flux de travail que j'ai décidé. J'ai écrit un script bash pour automatiser le processus en utilisant gitpour pousser automatiquement les modifications de PC1 à PC2 via un référentiel distant, tel que github. Jusqu'à présent, cela fonctionne très bien et j'en suis très satisfait. C'est beaucoup beaucoup plus rapide que rsync, plus fiable à mon avis, car chaque PC maintient un repo git fonctionnel et utilise beaucoup moins de bande passante pour effectuer toute la synchronisation, donc c'est facilement faisable sur un hot spot de téléphone portable sans utiliser des tonnes de vos données.

Installer:

1. Installez le script sur PC1 (cette solution suppose que ~ / bin est dans votre $ PATH):

   git clone https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles.git
   cd eRCaGuy_dotfiles/useful_scripts
   mkdir -p ~/bin
   ln -s "${PWD}/sync_git_repo_from_pc1_to_pc2.sh" ~/bin/sync_git_repo_from_pc1_to_pc2
   cd ..
   cp -i .sync_git_repo ~/.sync_git_repo

2. Maintenant, éditez le fichier "~ / .sync_git_repo" que vous venez de copier ci-dessus, et mettez à jour ses paramètres en fonction de votre cas. Voici les paramètres qu'il contient:

   # The git repo root directory on PC2 where you are syncing your files TO; this dir must *already exist* 
   # and you must have *already `git clone`d* a copy of your git repo into it!
   # - Do NOT use variables such as `$HOME`. Be explicit instead. This is because the variable expansion will 
   #   happen on the local machine when what we need is the variable expansion from the remote machine. Being 
   #   explicit instead just avoids this problem.
   PC2_GIT_REPO_TARGET_DIR="/home/gabriel/dev/eRCaGuy_dotfiles" # explicitly type this out; don't use variables
   
   PC2_SSH_USERNAME="my_username" # explicitly type this out; don't use variables
   PC2_SSH_HOST="my_hostname"     # explicitly type this out; don't use variables

3. Git clone votre dépôt que vous souhaitez synchroniser sur PC1 et PC2.

4. Assurez-vous que vos clés ssh sont toutes configurées pour pouvoir pousser et tirer vers le référentiel distant à partir de PC1 et PC2. Voici quelques liens utiles:
   1. https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh
   2. https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
5. Assurez-vous que vos clés ssh sont toutes configurées pour ssh de PC1 à PC2.

6. Maintenant, cddans n'importe quel répertoire du repo git sur PC1, et exécutez:

   sync_git_repo_from_pc1_to_pc2

7. C'est tout! Environ 30 secondes plus tard, tout sera synchronisé par magie de PC1 à PC2, et il imprimera la sortie tout le temps pour vous dire ce qu'il fait et où il le fait sur votre disque et sur quel ordinateur. Il est également sûr, car il n'écrase ni ne supprime tout ce qui n'est pas validé. Il le sauvegarde d'abord à la place! En savoir plus ci-dessous pour savoir comment cela fonctionne.

Voici le processus utilisé par ce script (c'est-à-dire: ce qu'il fait réellement)

1. À partir de PC1: il vérifie si des modifications non validées sont sur PC1. Si tel est le cas, il les engage dans un commit temporaire sur la branche actuelle. Il force alors les pousse vers une branche SYNC distante. Ensuite, il désengage sa validation temporaire qu'il vient de faire sur la branche locale, puis il remet le dépôt git local exactement comme il était en mettant en scène tous les fichiers qui étaient précédemment mis en scène au moment où vous avez appelé le script. Ensuite, c'est une rsynccopie du script sur PC2, et fait unssh appel pour dire à PC2 d'exécuter le script avec une option spéciale pour simplement faire des choses PC2.
2. Voici ce que fait PC2: il cdest dans le référentiel et vérifie si des modifications locales non validées existent. Si tel est le cas, il crée une nouvelle branche de sauvegarde dérivée de la branche actuelle (nom d'exemple:.my_branch_SYNC_BAK_20200220-0028hrs-15sec <- notez que YYYYMMDD-HHMMhrs - SSsec), et valide toutes les modifications non validées dans cette branche avec un message de validation tel que DO BACKUP OF ALL CHANGEMENTS SANS ENGAGEMENT SUR PC2 (PC CIBLE / BUILD MACHINE). Maintenant, il extrait la branche SYNC, en la tirant du référentiel distant si elle n'est pas déjà sur la machine locale. Ensuite, il récupère les dernières modifications sur le référentiel distant et effectue une réinitialisation matérielle pour forcer le référentiel SYNC local à correspondre au référentiel SYNC distant. Vous pourriez appeler cela une "traction difficile". C'est sûr, cependant, car nous avons déjà sauvegardé toutes les modifications non validées que nous avions localement sur PC2, donc rien n'est perdu!
3. C'est tout! Vous avez maintenant produit une copie parfaite de PC1 à PC2 sans même avoir à vous assurer que les répertoires de travail sont propres, car le script a géré tous les validations automatiques et tout le reste pour vous! Il est rapide et fonctionne très bien sur d'énormes référentiels. Maintenant, vous disposez d'un mécanisme simple pour utiliser n'importe quel IDE de votre choix sur une machine tout en construisant ou en testant sur une autre machine, facilement, via un point d' accès wifi à partir de votre téléphone portable si nécessaire, même si le référentiel est de dizaines de gigaoctets et que vous avez le temps et ressources limitées.

Ressources:

1. L'ensemble du projet: https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles
   1. Voir des tonnes de liens et de références supplémentaires dans le code source lui-même dans ce projet.
2. Comment faire un "hard pull", comme je l'appelle: Comment forcer "git pull" à écraser les fichiers locaux?

En relation:

1. git repository sync entre les ordinateurs, lors de déplacements?