qmakeツールを使用したプロジェクトへの静的ライブラリの簡単な接続

qbsは確実に登場しますが、今のところはqmakeに座っています(ずっと前にCMakeで逃げなかった場合)。 そして、おそらく、静的ライブラリをプロジェクトに接続した人なら誰でも、喜びが平均よりはるかに低いことに同意するでしょう。 個人的に、私はそのような不名誉のためにあまりにも怠amであり、プロセスを自動化することにしました。 カットの下-私がやったこと。



いくつかのコメント。 第一に、投稿形式では、以下で言及する多くのことの意味を詳細に説明することはできません。 これらの詳細に興味がある人は、qmakeに関するぽっちゃりした一連の投稿を書いた私のブログをチェックしてください 。 第二に、Qt 4の以下のスクリプトは、変更を加えないと機能しません。 私は完全にQt 5に切り替えました。それでも、Windowsでプログラムし、他のプラットフォームをサポートするには、小さな変更も必要です。



アイデア



すべての静的ライブラリに名前を付けてください。 そしてプロジェクトでは、この名前を変数に追加するだけで、MYLIBSを追加します。 このように:



MYLIBS += MyAwesomeLib
      
      





以下を実行する必要があります。

  1. プロジェクトがコンパイルされるのと同じ構成でコンパイルされるライブラリはリンクする必要があります。
  2. ライブラリが他のライブラリを使用する場合、それらは自動的にリンクする必要がありますが、リンクのみで、INCLUDEPATHが詰まらないようにする必要があります。
  3. 静的ライブラリを再構築すると、プロジェクトがリンクされます。


3番目の段落は単純に実装され、2番目の段落も簡単です。ただし、最初の段落ではソースコードの編成に関するいくつかの条件が必要です。 個人的に、私は常にシャドウビルドを使用し、Qt Creatorが生成するときにディレクトリ名を残します。 次に、同様のディレクトリ名で簡単に目的のライブラリオプションを見つけることができます。



機能設定



MYLIBS変数を実装するには、機能メカニズムを使用します。 自己記述の機能をシステムディレクトリ(mkspes/ features)にスローできますが、これは好ましくありません。 私の行動は異なります。ソースのルートディレクトリ(プロジェクトはすべてこのディレクトリのサブディレクトリ)に、次の内容の.qmake.cacheファイルを作成しました。



 #    ,       QMAKEFEATURES = D:/sources/sys/qmake/features
      
      





このディレクトリに、MYLIBS実装自体を含むmylibs.prfファイルを作成しました。 MYLIBS変数を機能させるには、プロジェクトファイルに次の行を追加します。



 CONFIG += mylibs
      
      





mylibs.prf



コメントは、何が起こっているかの本質を明確にする必要があります。 つまり、ライブラリは再帰的に処理されます。最初にMYLIBS変数で指定されたライブラリ、次に処理されたライブラリで使用されるライブラリなど。



 #      shadow build    __outpath = $$basename(OUT_PWD) MYLIB_CONFIG = $$section(__outpath, "-", 2) unset(__outpath) # -,     win32-msvc* { MYLIB_PREFIX = MYLIB_EXT = .lib } else { #mingw MYLIB_PREFIX = lib MYLIB_EXT = .a } #     defineReplace(registerStandardMyLib) { libTargetName = $$1 libFolder = $$2 MYLIB_PATH = $${libFolder}/build-$${libTargetName}-$${MYLIB_CONFIG}/bin/$${MYLIB_PREFIX}$${libTargetName}$${MYLIB_EXT} isEmpty(MYLIB_NESTED) { INCLUDEPATH += $${libFolder}/$${libTargetName}/include export(INCLUDEPATH) } isEqual(TEMPLATE, app) { LIBS += $${MYLIB_PATH} PRE_TARGETDEPS += $${MYLIB_PATH} export(LIBS) export(PRE_TARGETDEPS) } return($$MYLIB_PATH) } #       MYLIBS #       .pri   lib #   mylib.prf.   =  . #     ,    # .pri        MYLIBS. #     ,      . # 100   -   __iterlist = 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 AAA MYLIB_NESTED = __handled_libs = for(__iter, __iterlist) { isEqual(__iter, AAA) { error(MYLIBS: level of nesting limit is reached!) } __mylibs = $$unique(MYLIBS) __mylibs -= __handled_libs isEmpty(__mylibs): break() clear(MYLIBS) for(__mylib, __mylibs) { !exists($${PWD}/lib/$${__mylib}.pri) { error(Libary $$__mylib is not configured.) } include($${PWD}/lib/$${__mylib}.pri) __handled_libs += __mylib } MYLIB_NESTED = 1 } unset(__mylib) unset(__iter) unset(__iterlist) unset(__handled_libs)
      
      







実際、ライブラリは同じ名前の.priファイルでプロジェクトに接続されています。このファイルは、機能mylibs.prfの隣のlibディレクトリに配置する必要があります。 プラグインライブラリにそのようなファイルがない場合、qmakeはエラーをスローします。



MyAwesomeLib.priは次のようになります。



 MYLIB_PATH = D:/sources/libs/build-MyAwesomeLib-$${MYLIB_CONFIG}/bin/$${MYLIB_PREFIX}MyAwesomeLib$${MYLIB_EXT} #      INCLUDEPATH isEmpty(MYLIB_NESTED) { INCLUDEPATH += D:/sources/libs/MyAwesomeLib/include } #  -    isEqual(TEMPLATE, app) { LIBS += $${MYLIB_PATH} #     PRE_TARGETDEPS += $${MYLIB_PATH} } #  MyAwesomeLib   MyBeyondAwesomeLib,     MYLIBS += MyBeyondAwesomeLib
      
      





ご覧のとおり、落書きがたくさんあります。ネストの処理など、さまざまなニュアンスを考慮する必要があります。 私が病理学的に怠け者であり、ほとんどすべてのライブラリが同じように編成されていることを考えると、 registerStandardMyLib



関数を作成しました。そのコードは上記のmylibs.prfで提供されています。 したがって、私の.priライブラリファイルの大部分は次のようになります。

 $$registerStandardMyLib(MyAwesomeLib, D:/sources/libs) MYLIBS += MyBeyondAwesomeLib
      
      





以上です。 誰かが役に立つといいな。



All Articles