SSH経由でEclipseを使用してリモートプロジェクトで作業する

私は次の箱を持っています：

1. Eclipse CDTを備えたWindowsボックス
2. Linuxボックス。SSH経由でのみアクセスできます。

プロジェクトのビルドと実行に必要なコンパイラーとハードウェアの両方がマシンBのみにあります。

私はEclipse CDTを使用して、そのプロジェクトのWindowsボックスから「透過的に」作業し、IDE内からリモートでプロジェクトをビルド、実行、デバッグできるようにしたいと考えています。

どのように設定しますか：

• 建物は機能しますか？ローカルのメイクファイルを作成しrsyncてプロジェクトを作成し、リモートのメイクファイルを呼び出して実際のビルドを開始するよりも簡単な解決策はありますか？Eclipse管理ビルドにはそのための機能がありますか？
• デバッグは機能しますか？
• できれば-Eclipse CDTコードのインデックス作成は機能しますか？必要なすべてのヘッダーファイルをマシンBからマシンAにコピーし、それらを手動でインクルードパスに追加する必要がありますか？

リモートシステムエクスプローラーを試す（RSE）を。それはあなたが望むものを正確に行うためのプラグインのセットです。

RSEは現在のEclipseインストールにすでに含まれている場合があります。Eclipse Indigoをチェックインするには、[ ウィンドウ] > [パースペクティブを開く] > [ その他...]に移動し、[パースペクティブを開く]から[ リモートシステムエクスプローラー]を選択します。を開く] ]に移動しを開く]ダイアログから[ ]をてRSEパースペクティブを開きます。

EclipseのRSEパースペクティブからSSHリモートプロジェクトを作成するには：

1. 新しい接続を定義し、[New Connection]ダイアログの[Select Remote System Type]画面から[SSH Only]を選択します。
2. 接続情報を入力し、[完了]を選択します。
3. 新しいホストに接続します。（SSH鍵がすでにセットアップされていると想定しています。）
4. 接続したら、ホストのSftpファイルにドリルダウンし、フォルダーを選択して、アイテムのコンテキストメニューから[ リモートプロジェクトの作成 ]を選択します。（リモートプロジェクトが作成されるのを待ちます。）

正しく行われていれば、プロジェクトエクスプローラーやEclipse内の他のパースペクティブからアクセスできる新しいリモートプロジェクトがあるはずです。SSH接続を正しく設定すると、パスワードを通常のSSH認証プロセスのオプションの一部にすることができます。SSH経由のEclipseを使用したリモートプロジェクトが作成されます。

最も簡単な方法は、LinuxボックスでEclipse CDTを実行し、X11転送またはVNCなどのリモートデスクトップソフトウェアを使用することです。

もちろん、これは、EclipseがLinuxボックスに存在し、ボックスへのネットワーク接続が十分に高速である場合にのみ可能です。

利点は、すべてがローカルであるため、同期の問題が発生せず、厄介なクロスプラットフォームの問題が発生しないことです。

ボックスに日食がない場合は、SMB（またはSSHFS）を介してLinux作業ディレクトリを共有し、Windowsマシンからアクセスすることを考えることができますが、かなりの設定が必要になります。

特にクロスプラットフォームの場合は、どちらも2つのコピーを持つよりも優れています。

私と同じ場所（または以前）でしたが、FWIWはLinuxホストのsamba共有にチェックアウトし、その共有をWindowsマシンでローカルにnotepad ++で編集してから、PuTTYを介してLinuxボックスでコンパイルしました。（Linuxホスト上のエディターの10個のバージョンの更新は許可されておらず、Javaもなかったため、X11転送をあきらめました）

今... Windowsホスト上のVMで最新のLinuxを実行し、必要なすべてのツール（CDTなど）をVMに追加してから、RTEによく似たchroot jailをチェックアウトしてビルドします。

それは不格好な解決策ですが、私はそれをミックスに投入すると思いました。

私のソリューションは、sshfsを使用することを除いて、SAMBAのソリューションに似ています。リモートサーバーをsshfsでマウントし、リモートマシンでmakefileプロジェクトを開きます。そこから行きます。

このようにして、MercurialのGUIフロントエンドも実行できるようです。

リモートコードの作成は次のように簡単です：ssh address remote_make_command

私はデバッグするためのまともな方法を探しています。おそらくgdbserver経由ですか？

私は2年前に同じ問題を抱えていて、次の方法で解決しました。

1）私はEclipseで管理されていないメイクファイルでプロジェクトをビルドします2）Eclipse内のファイルを編集するためにSAMBA接続を使用します3）プロジェクトのビルド：EclipseはLinuxへのSSH接続を開くメイクファイルで「ローカル」メイクを呼び出しますホスト。SSHコマンドラインでは、Linuxホストで実行されるパラメーターを指定できます。私はそのパラメーターにLinuxホスト上の「実際の」makeを呼び出すmakeit.shシェルスクリプトを使用します。ビルドのさまざまなターゲットは、ローカルのmakefile-> makeit.sh-> Linuxホストのmakefileからのパラメーターでも指定できます。

私は試した ssh -Xが、たまらなく遅いです。

私もRSEを試しましたが、Makefileを使用したプロジェクトのビルドもサポートしていませんでした（回答を投稿してから、これは変更されたと言われています、まだ試していません）

NXはX11フォワーディングより高速であると読みましたが、動作させることができませんでした。

最後に、私のサーバーがX2Goをサポートしていることがわかりました（ご使用のサーバーがサポートしていない場合、リンクにはインストール手順があります）。今私はしなければならなかった：

• サーバーにEclipseをダウンロードして解凍します。
• ローカルマシン（sudo apt-get install x2goclientUbuntu）にX2Goをインストールし、
• 接続を構成します（ホスト、sshキーを使用した自動ログイン、Eclipseの実行を選択）。

ビルド、デバッグ、コードインデックス作成など、すべてがローカルマシンで作業しているかのようです。そして、顕著な遅れはありません。

この場合、ソースの参照とビルドにptp eclipse https://eclipse.org/ptp/を使用できます。

このプラグインを使用してアプリケーションをデバッグできます

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

この回答は現在、2台のLinuxコンピューター（またはMacでも動作する可能性がありますか？-Macでテストされていません）の使用にのみ適用されます（この同期スクリプトをbashで記述したため）。gitただし、これは単にのラッパーです。したがって、必要に応じて、それをクロスプラットフォームのPythonソリューションまたは何かに変換してください。

これはOPの質問に直接答えることはありませんが、非常に近いので、このページにアクセスした他の多くの人々の質問にも答えることを保証します（実際には、自分自身の解決策を書く前にここに来たので、私も含まれています）。とにかくここに投稿しています。

したい：

1. 軽量のLinuxコンピューターでEclipseのような強力なIDEを使用してコードを開発し、
2. 別のより強力なLinuxコンピューター上でsshを介してそのコードをビルドします（Eclipse内からではなく、コマンドラインから）

コード「PC1」（パーソナルコンピューター1）を作成する最初のコンピューターと、コード「PC2」を作成する2番目のコンピューターを呼び出します。PC1からPC2に簡単に同期するツールが必要です。私はを試しましたがrsync、大規模なリポジトリの場合は非常に遅く、大量の帯域幅とデータを消費しました。

それで、どうすればいいですか？どのワークフローを使用する必要がありますか？この質問もあるなら、ここに私が決めたワークフローがあります。gitgithubなどのリモートリポジトリを介してPC1からPC2に変更を自動的にプッシュすることでプロセスを自動化するbashスクリプトを作成しました。これまでのところ、それは非常にうまく機能し、私は非常に満足しています。各PCが機能するgitリポジトリを維持し、全体の同期を実行するためにはるかに少ない帯域幅を使用するので、私よりもはるかに高速でrsync信頼性が高く、大量のデータを使用せずに携帯電話のホットスポットで簡単に実行できます。

セットアップ：

1. PC1にスクリプトをインストールします（このソリューションは〜/ binが$ 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. 次に、上記でコピーした「〜/ .sync_git_repo」ファイルを編集し、ケースに合わせてパラメーターを更新します。含まれるパラメータは次のとおりです。

   # 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. PC1とPC2の両方で同期するリポジトリをGitで複製します。

4. PC1とPC2の両方からリモートリポジトリにプッシュおよびプルできるように、sshキーがすべて設定されていることを確認します。ここにいくつかの役立つリンクがあります：
   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. sshキーがすべてPC1からPC2へのsshに設定されていることを確認します。

6. 今cdPC1、および実行のGitリポジトリ内の任意のディレクトリに：

   sync_git_repo_from_pc1_to_pc2

7. それでおしまい！約30秒後、すべてがPC1からPC2に魔法のように同期され、何が行われているのか、ディスク上でどのコンピューター上で行われているのかを伝えるために、常に出力が印刷されます。コミットされていないものを上書きまたは削除しないため、安全です。代わりに最初にバックアップします！仕組みについては、以下をご覧ください。

このスクリプトが使用するプロセスは次のとおりです（つまり、実際に何をしているのか）

1. PC1から：コミットされていない変更がPC1にあるかどうかを確認します。もしそうなら、それはそれらを現在のブランチの一時的なコミットにコミットします。次に、それらをリモートのSYNCブランチに強制的にプッシュします。次に、ローカルブランチで行った一時的なコミットのコミットを解除し、スクリプトを呼び出したときに以前にステージングされたファイルをステージングすることにより、ローカルのgitリポジトリを元の状態に戻します。次に、rsyncスクリプトのコピーをPC2にコピーし、sshPC2に特別なオプションを指定してスクリプトを実行するようにPC2に指示する呼び出しを実行します。
2. PC2が行うことは次のとおりです。PC2はcdリポジトリに格納され、ローカルのコミットされていない変更が存在するかどうかを確認します。その場合は、現在のブランチから分岐した新しいバックアップブランチ（サンプル名：my_branch_SYNC_BAK_20200220-0028hrs-15sec<-YYYYMMDD-HHMMhrs--SSsec）を作成し、などのコミットメッセージを使用して、コミットされていない変更をそのブランチにコミットします DO BACKUP OF ALL PC2（ターゲットPC /ビルドマシン）でのコミットされていない変更。これで、SYNCブランチがチェックアウトされ、ローカルマシンにまだない場合は、リモートリポジトリからプルされます。次に、リモートリポジトリの最新の変更をフェッチし、ハードリセットを実行して、ローカルのSYNCリポジトリをリモートのSYNCリポジトリに一致させます。これを「ハードプル」と呼ぶかもしれません。ただし、PC2でローカルに行ったコミットされていない変更はすべてバックアップ済みであるため、何も失われないので安全です。
3. それでおしまい！これで、スクリプトがすべての自動コミットやその他の処理を行ったので、クリーンな作業ディレクトリを保証する必要なく、PC1からPC2への完全なコピーが作成されました。高速で、巨大なリポジトリで非常にうまく機能します。これで、リポジトリが数十ギガバイトで時間がある場合でも、必要に応じて携帯電話からWi-Fiホットスポットを介して、別のマシンでビルドまたはテストしながら、任意の IDEを1つのマシンで使用する簡単なメカニズムが手に入りました。およびリソースに制約があります。

リソース：

1. プロジェクト全体：https : //github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles
   1. このプロジェクト内のソースコード自体に、さらに多くのリンクと参照が表示されます。
2. 「ハードプル」と呼んでいる方法：「git pull」でローカルファイルを強制的に上書きするにはどうすればよいですか？

関連：

1. 移動するときにコンピューター間でgitリポジトリを同期しますか？