簡単な紹介
私は約15年間C ++開発を行っており、かつてWatcom Cで始めました。 私は彼のいい思い出があります。 しかし、UNIXコンソール用にもっと書く必要があったので、IDEとしてvimに切り替えました。 一般的に、非常に便利です。 そのプラグインは驚くほど機能し、オートコンプリートを設定し、クラス階層を表示し、定義にすばやくジャンプしたり、検索したりできます。一般的に、IDEでできることはすべてここで上げることができます。 痛みは、新しいプラグインをインストールしてマスターしようとしているときに発生します。 それはすべてではなく、常にではなく、すべてのJavaよりも多くのパーセントとメモリを消費します。
Qt Creatorを時々見ました。 しかし、彼はあえてそれに切り替えませんでした。
最初の知り合い
そのため、これらの瞬間の1つでCLionに出会いました。 コンストラクターがvimを呼び出した後、私は本当に「箱から出して」ソリューションを取得したかったのです。 一見したところ、私は彼が本当に好きでした。 クイックヒント、簡単なナビゲーション、cmakeプロジェクトでの作業、ネイティブプロジェクトでの作業、vimモードのサポート（後でオフにしました）。
残念なことにすぐに起こった。 実際のところ、現時点では主にlinuxで書いていますが、ワークステーションとしてmacbook proがあります。 はい、そうです！ そして、私は、アップルのラップトップを買って、macOS以外のものをインストールする人を変質者と考えています。 したがって、リモートでビルドまたはドッカーを介してビルドする機能は私にとって非常に重要です。 そして、何人のユーザーがリクエストしたとしても、まだCLionにはありません。 移行の最初の試みは何も終わりませんでした。「すぐに使える」ソリューションはありません。
二度目の試み
しかし、vimの設定の苦労はどこにも行きませんでした。私はCLionにもう一度チャンスを与えることにしました-私が以前直面した問題を自分で解決しようとするため そしてこれ：
- ローカルにインストールされたライブラリの欠如。 CLionは、説明が表示されないクラスに対してヒントを提供できません
- アセンブリ自体
その前に、OSと共にパッケージに入っているライブラリを使用しました。 CLionでは、すべてのOSヘッダーファイルをMacにドロップする必要がありましたが、これは絶対に必要ありませんでした。 しかし、コナンは私を助けてくれました。 コンパイルされたすべてのライブラリを個別のディレクトリに保存し、簡単に自分自身にアタッチできます。
2つ目では、すべてがそれほど単純ではありませんでした。 cmakeを、dockerコンテナー内でビルドするスクリプトに置き換えることにしました。 レポジトリからコードを同期するたびに微笑んだり、CMakeLists.txtに追加のターゲットを追加/削除したりすることは勧められていませんでした。 私は、プロジェクトを複製し、タンバリンと踊らずにすぐに集まってみたいと思っていました。 それほど単純ではありませんでした。 主な困難は、ツールチェーンを変更するときに実行するCLionテストプロジェクトのアセンブリと、コンテナ内のスペースを含むパラメーターの転送でした。 しかし、私はそれをやった。
すべてが順調であれば-まだすべてを知らない
それは思われる-私はそれをやった！
...
C ++ 14またはC ++ 17を使用してC ++でビルドするのはかなり遅いと聞きましたが、最初はすべてをコンパイラの遅さに起因すると考えました。 しかし、その後、彼はリモートで専用サーバー上で何らかの形でスマートになりすぎていることに気付きました。 プロジェクトが大きくなるほど、私の魂に大きな疑問が生じました。
港湾労働者は二重底で終わった。 はい、サーバーはすぐに立ち上がります。オーバーレイよりも3倍遅いため、osxfsでのコンパイルのみが機能します。 したがって、rsyncの使用に切り替える必要がありました。 また、Dockerボリュームの設定を発見しました。 委任を使用すると、ビルド速度が15％向上します。
途中で、忍者のビルド時間を標準のmakeに対して測定しました-差はほぼ2回現れました。 True CLionを使用するには、makeを使用する必要があります。それ以外の場合は、ヒントに別れを告げます。 アセンブリを2回実行する必要がありました。1回はmakeを使用し、2回目は忍者を介してCLionを実行しました。 ここでの利点は、プロジェクトがめったに変更されず、頻繁に集まる必要があることです。
また、プリコンパイル済みヘッダー（cotire）を使用してみました-効果はあいまいでした。 さらに、これにはstdafx.h（またはその他のファイル）を手動で生成し、すべての.cppに含める必要がありました。 そして、これは順番に、CLionのようなものではありません。 彼は、他のすべてのインクルードが冗長であると考え始めます。 これは回避できますが、ゲインはそれほど大きくありませんでした。
最後にしたことは、ccacheを放棄することでした。 私の場合、約1秒の遅延が発生しました。 はい、適切なファイルが見つかった場合、これによりアセンブリが高速化されます。 しかし、新しいコードを書くとき、これはしばしば起こりません。
食欲は食事に伴う
アセンブリが起動したので、プッシュしてデバッグしてみてください！
以前は、Docker内のgdbを起動できないと考えていました。 これはそうではないことが判明しました。 --security-opt seccomp：unconfinedオプションはこの問題を取り除きます 。 また、この記事では、構成方法と構成について詳しく説明しています。 しかし、その後、予期せぬ事態が発生しました。 私はclang（論理的）を実行していましたが、デバッグにはgccを使用する必要があります。 それ以外の場合は、デバッガーでアプリケーションを実行できますが、stlコンテナー内の値は表示できなくなります。 基本的に、gccを介したビルドは問題ではありません。 次に、それは本当に機能します。
エピローグ
マウスは泣き、刺されましたが、サボテンを食べ続けました...私たちは待っています！ リモートアセンブリを待っています。 C ++ 17の完全なサポートを待っています。 JetBrainsとJFrogは常にニュースレターでお互いに言及していますが、まだ統合されていません。 ローカルで組み立てる場合でも、conanコマンドを手動で入力する必要があります。 待ってます！
また、忍者を通じてビルドのサポートを取得できると便利です。 道路の生産性の50％は横になっています。
テンプレートを作成するための私のスクリプトとDockerfileはGitHubにあります 。