繰り返しになりますが、Qt Labsブログで気付かれず、Qt Creator 2.3のリリースがハブで気付かれなかったというニュースがありました。 変更点の一覧を見ると、いつものようにクールなパンがたくさんありますが、その中の1つに非常に興味がありました。 つまり、開発環境から直接sshを使用して、リモートLinuxマシンにアプリケーションをデプロイおよびデバッグします。
なぜこれが面白かったのですか？ はい、なぜなら：
1）私たちのオフィスに
は鉄の腕があり、Qt / Embedded + Linuxに基づいた独自のファームウェアが徐々に見られています。
2）Qtを使用して作成されたプログラムの次のバージョンのクロスコンパイル、展開、およびデバッグは、ご想像のとおり、使用の必要性を考慮して信じられないほどの喜びと性的満足をもたらします
build.sh、deploy.shなどの自作スクリプトの束。
3）生産性が低下しますが（迷惑のレベルが上がります）、Android灯台のソースコードを掘り下げて、そこからパッケージを仮想Androidスマートフォンに展開する方法を盗み始めました。
何が提供されていますか？ ご存じのように、Qt Creatorには、Symbian（USB-MicroUSB経由）およびMaemo（ssh経由）にアプリケーションをデプロイするためのツールがすでにありました。 このバージョンではどうやら、開発者はアイデアを思い浮かべることを決め、Maemoデプロイメントツールの統合により、アプリケーションを通常のLinuxマシンにデプロイできるようにしました。
自由に設定にいくつかの新しいタブがあります：
- インストルメンテーション-ここでコンパイラを指定できます。 もちろん、単純なコンパイラーとクロスコンパイラーの両方です。
- Linuxデバイス-ここでは、リモートマシンでアセンブルされたアプリケーションの展開設定を確認できます
行こう
初期条件：
Qt Creator 2.3 Beta開発環境が存在する主要なLinuxマシンはgdbであり、必要なプログラムのソースコードがあります。
sshアクセスとgdbserverがインストールされたリモートLinuxデバイス。
アセンブリ（もちろんコンパイル済みのQt / Embeddedを使用）およびクロスコンパイラ用のクロスツールチェーン。 これは、たとえば、私の場合のように、ソースと同じマシン上に存在することはなく、隣接するサーバー上にも存在します。 そのnifigaはタスクを容易にしません...しかし、それでもこの例で説明します。 Buildrootはツールキットとして使用され、codesourceryは一連のコンパイラとして使用されます。 プラットフォーム-ARM（armv7a）。
したがって、最初に行うべきことは、qmakeにQtのクロスコンパイルバージョンについて質問することです。
# /root/openaos/br11_glibc_building/output/staging/usr/bin/qmake -v QMake version 2.01a Using Qt version 4.7.1 in /root/openaos/br11_glibc_building/output/staging/usr/lib
ライブラリの場所についてのこの種のヒント。 念のため、ファイルを見てください
/root/openaos/br11_glibc_building/output/staging/usr/mkspecs/qws/linux-arm-g++/qmake.conf
ツールチェーンが示されていることを確認するには、非常に正しいことがあります。
QMAKE_LFLAGS = -L/root/openaos/br11_glibc_building/output/staging/lib -L/root/openaos/br11_glibc_building/output/staging/usr/lib QMAKE_CXXFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mab$ QMAKE_CFLAGS = --sysroot=/root/openaos/br11_glibc_building/output/staging -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -Os -mtune=cortex-a8 -march=armv7-a -mabi=$ QMAKE_STRIP = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-strip QMAKE_RANLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ranlib QMAKE_OBJCOPY = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-objcopy QMAKE_AR = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-ar cqs QMAKE_LINK_SHLIB = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_LINK = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ --sysroot=/root/openaos/br11_glibc_building/output/staging QMAKE_CXX = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-g++ QMAKE_CC = /root/codesourcery/arm-2010.09/bin/arm-none-linux-gnueabi-gcc
準備作業の次の段階は、sshfsに必要なすべてのディレクトリをマウントして、ツールチェーンなどがどこにもマウントされず、同じマシンにあるはずの場所にあるようにします。 ご
想像のとおり 、2つのディレクトリをマウントする必要があります：
/ root / codesourcery /および
/ root / openaos / br11_glibc_building /やること...
$ sudo chmod 777 /root $ cd /root $ mkdir oabroot $ sshfs root@openaos-build.lan.arta.kz:/ oabroot/ $ ln -s oabroot/root/openaos/ ./ $ ln -s oabroot/root/codesourcery/ ./ $ ls -l 4 lrwxrwxrwx 1 kafeg kafeg 26 2011-07-22 16:10 codesourcery -> oabroot/root/codesourcery/ drwxr-xr-x 1 root root 4096 2011-07-13 08:44 oabroot lrwxrwxrwx 1 kafeg kafeg 21 2011-07-22 16:10 openaos -> oabroot/root/openaos/
はい、もちろん、ルートディレクトリにこのような権限を付与するのは少しく、一般的に骨が見えます...しかし、このアセンブリガベージをすべて展開したときに何をすべきか、経験と時間はほとんどありませんでした...そして仮想マシンでは、ルートを使用してみませんか？
それでも、私たちは続けます。 実際、現時点では、ホストマシンで既にアセンブリツールが使用可能であり、
ls / root / openaos / br11_glibc_building / output / staging / usr / libのようなものを実行すると、欠落しているディレクトリに関するメッセージは表示されませんが、少なくとも十分ですls応答を禁止し、数百のファイルを出力しました。 時々、どうして地獄がこんなに必要なのか... =）
わかった 作成者を実行し、設定に移動します。 まず最初に、新しく作成されたQtへのパスを示す価値があります（この時点でhabrastorageが死んだため、私はst迷しましたが、私たちのものは消えませんでした...）。
この写真から、開発環境がライブラリ自体と他のゴミを見つけたのは明らかですが、これをすべてコンパイルする方法とツールチェーンを入手する場所を彼女が知らなかったことが非常に怒っていました。 説明してください...
これを行うには、「ツールキット」セクションに移動して、新しいGCCタイプコンパイラを追加し、必要なフィールド（コンパイラとデバッガへのパス）を入力します。
もう一度、Qtセクションに戻り、出来上がったツールチェーンに関するメッセージが消えました：
設定ダイアログの最後のタッチは、アプリケーションをデプロイするデバイスを追加することです...簡単なことはありません。[Linuxデバイス]セクションに移動し、[追加]ボタンをクリックします-> [Generic Linux Device]->ウィザードフィールドに入力してセットアップを完了します。 接続テストのウィンドウがすぐに表示されます。
注目すべきは、リモートマシンにパスワードを持ちたくない場合、接続設定インターフェイスからsshキーのペアをすぐに生成し、デバイスに公開キーを展開することもできます。 そして、静かにパスワードを削除するか、パスワードを忘れます...確かに、1つのバグがまだここに存在しています。 公開鍵は<user directory> /。Ssh / authorized_keysに記録されるため、たとえば、ドロップベアではなくデバイスに完全なsshサーバーがインストールされている場合、鍵認証は機能します。 また、仮想マシンでリモートLinuxを実行することを妨げるものは何もないことを示唆する「デバイスタイプ」項目にも注意を払う価値があります。 もちろん、それはすでに明らかでしたが...
[OK]をクリックして、設定ダイアログを閉じます。 それだけですか？ 図=）
鉄片に関連するプロジェクトを開き、「プロジェクト」タブに移動して、アセンブリの構成を必要なものに変更します。
ご覧のとおり、構成を変更すると、必要なQtバージョンと必要なツールチェーンが自動的に選択されました。 確かに、ここではまだ2番目のバグを待っています-どのQtプロファイルが選択されていても、デフォルトでは-specパラメーターはlinux-g ++に等しくなります。 「-spec qws / linux-arm-g ++」が必要です。これは、
qmakeビルドフェーズの[詳細オプション]フィールドに書き込むことで修正できます。 これが行われない場合、もちろん多くの恐ろしい間違いがあります：
... qatomic_arm.h:131: Error: no such instruction: `swpb
また、起動設定を変更する必要があります-新しい設定「TarballをビルドしてLinuxホストにインストール」を追加し、表示されるウィンドウで、インストールするファイルのリストから必要なサブプロジェクトを選択し、同意して、何かを変更する必要がある場合... 、特定のファイルのインストールパスを変更する場合は、プロジェクトファイル内で次のようなディレクティブを使用してすべてを構成します。
unix:!symbian:!maemo5:isEmpty(MEEGO_VERSION_MAJOR) { target.path = /opt/authorize/bin INSTALLS += target }
次に、少し下にアプリケーション起動の新しいバージョン「bin_name（remote）」を追加し、サンプルの「-qws」にパラメーターを追加します。これは、まだ組み込みバージョンのライブラリーのアプリケーションであるためです。 次のようになります：
すでに悪くない...次は何ですか？ 次に-収集してみてください！ エディター->ビルド（Esc-> Ctrl + R）。 そして、アプリケーションが組み立てられるまで待ちます。 私の場合、これは最も長い手順です...
コーヒーを飲む？ 今、あなたのハードウェアを見てください...あなたのアプリケーションウィンドウはそこに現れましたか？ すべてがうまくいっていれば、それはすでにあるはずです...
ちょうど...プロジェクト内に、実際のアプリケーションに加えて、共有ライブラリもある場合、tarアーカイブを構築してデバイスにアップロードする段階で、次のようなエラーが発生します。
Creating package file ... Error reading file '/root/oabroot
もちろん、これは簡単に修正できますが、アプリケーションアセンブリの最後にこのようなエラーメッセージを受け取るのはあまり良いことではありません。 プロジェクトに含まれるすべての共有ライブラリに対して、次のようなことをする必要があります。
$ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0 $ ln -s /root/oabroot/*/libqmlgestureareaplugin.so /root/oabroot/*/libqmlgestureareaplugin.so.1.0.0
最後に、最終的な修正後、開発環境の最終ログを確認できます。これは、その準備状況について既に叫んでいます。
そして、アプリケーションの起動ログは喜んで叫ぶ：
Killing remote process(es)... Starting remote process ... Remote process started. Killing remote process(es)...
実際...アプリケーションをデプロイするこの方法は、クロスアセンブリまたはリモート起動だけでなく、アプリケーションの配布を伴うtarアーカイブの自動アセンブリにも使用できます。 これを行うには、IPを展開するマシンとしてホストマシンを指定し、必要なインストール手順を.proファイルにプッシュするだけで十分です。 これにより、たとえば、QMLアプリケーションの開発の利便性が向上します。QMLアプリケーションでは、常にかかとに沿ってドラッグする必要のある小さなファイルがたくさんあります。 、これはSymbianのディストリビューションを構築するときにも使用されます。
以下にもう一度示す機能を示します。
a）ソフトウェア開発は簡単にできます
b）Qt開発者は主にユーザー（つまり、製品を使用している開発者）について考え、ライブラリ全体の生産性と魅力を高めるために可能な限りのことを行います。
ありがとう、誰かが役に立つことを願っています。