Lapack: システムの構築

リストに追加するために、CMakeビルドは現在（に見える）ライブラリの選択された部分（REAL、DOUBLE、COMPLEXおよび/またはDOUBLE COMPLEX）のみをビルドするオプションをサポートしていますが、Makefileのみのビルドはサポートしていません。 （OpenBLASで配布するコピーのMakefileを変更し、必要に応じてPRを作成できます。ここで関係のない変更を除外するには、再差分する必要があります）

CMakeビルドは現在（に見える）ライブラリの選択された部分（REAL、DOUBLE、COMPLEXおよび/またはDOUBLE COMPLEX）のみをビルドするオプションをサポートしています

このオプションは、私が最後に試したとき（2020年5月頃）に機能しました。

CMakeビルドにはいくつかのオプションがあります。ここに私にとって最も重要なものをリストします。

• 共有ライブラリまたは静的ライブラリの構築
• テストの有効化または無効化
• 64ビットまたは32ビットのインデックス
• ビルドの最適化とデバッグ
• 行列生成ライブラリ（TMG）のオプション、他のBLASライブラリの使用法、BLAS ++、LAPACK ++ ..

良いアイデア。 makeを使用してマシンで動作しているが、CMakeを使用してciで動作していないビルドは、私を何度か夢中にさせました。

技術的には、Makefileはこれらのオプションの多くもサポートしていると思います（make.incを編集するだけです）。 テストなしでビルドしたい場合は、 make libビルドできます。 ただし、重要なのは、共有ライブラリの構築がサポートされていないことです。 ほとんどの人はLAPACKを共有ライブラリとして使用しているので、CMakeは私にとって明らかに勝者です。

最終的にそれを実行する場合は、Readmeにビルド手順を追加することをお勧めします。 テストを構築して実行する方法、フラグ、特にfrecursiveフラグを追加する方法。 おそらく、共有ライブラリの使用方法に関する小さなメモですらあります。

gmakeで共有ライブラリを構築するために、すでに多くのパッチが浮かんでいると思います（たとえば、lapackをパッケージ化するLinuxディストリビューション）。 すでに存在するBUILD_DEPRECATEDのようにmake.incにBUILD_SHAREDオプションを追加するのに複雑すぎないようにする必要があります（ccmakeとcmake-guiが存在することをすでに知っていない限り、どちらもCMakeビルドではかなりあいまいです）。

すでに存在するBUILD_DEPRECATEDのようにmake.incにBUILD_SHAREDオプションを追加するのに複雑すぎないようにする必要があります（ccmakeとcmake-guiが存在することをすでに知っていない限り、どちらもCMakeビルドではかなりあいまいです）。

これらのオプションを設定するためにccmakeを操作する必要はありません。 autotoolsによって生成されたconfigureスクリプトと同様のコマンドラインを使用できます。

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

確かに可能ですが、私のポイントは、CMakelists.txtを読む以外に明白なドキュメントがないということです（READMEはgmake用に事前構成されたmake.incファイルを指します）。 ccmakeとcmake-guiは利用可能なオプションのリストを表示しますが、これはcmakeを初めて使用する人には失われます。

CMAKEの使い方のドキュメントを書けば、CMAKEを使ったことがないので、モルモットのユーザーとして使うことができます。

会話全体を読んで、MakefileがLAPACKにあるのは私だけだと思います。 ;）

まあ、わかりません。

はい：いくつかのビルドシステムを維持すると、不整合が発生します。 だから私は1つだけを持っているという議論を見ます。 （CMAKE、make、mesonのいずれであっても。）（そうです、私もmesonを使ったことがありません。

CMAKEへの移行が心配です。使い方がわからないだけでなく、維持方法もわからないからです。 しかし、私たちには素晴らしいコミュニティがあり、プロジェクトのこの部分に取り組むことができないことは問題ではないようです。さらに、CMAKEを学ぶ必要があるでしょう。

すべて：このスレッドであなたの意見を表明してください。

私たちのほとんどは、（1）makeを削除して中間子を削除したいと思っているようです。 （2）CMAKEのみに移動します。 （3）CMAKEの使用方法に関するいくつかの優れたドキュメントを追加します。 私は元気です。

私はあちこちで他のパッケージメンテナにいくつかの電子メールを送り、彼らがどのようにやっているのか、そしてこの問題について彼らの意見は何であるかを尋ねるつもりです。

@ martin-frbg：これはOpenBLASでどのように行われますか？

OpenBLASには、「動作することが知られている」「従来の」ビルドシステムとしてMakefilesがあり、CMAKEは、生成するファイルがMakefileビルドの動作と正確に対応していない可能性があるという警告を発する、元々ユーザーが提供した代替手段です。
私はCMAKEがあまり好きではありませんが、動作する（おそらく非正統的な）cmakeビルドファイルを作成することを学びました。 私の意見では、Makefileはそのままにしておく必要があります（そして、gmakeはcmakeよりもまだ普及していると思います）。 メソンサポートの歴史はわかりません-_if_これは一度だけの「柵を越えた」貢献であり、誰も知らないか、更新を続けるのに十分気にかけていません。それを維持する意味はほとんどないと思います。

メソンサポートの歴史はわかりません。これが、更新を続けるのに十分なことを誰も知らない、または気にかけない、かつての「柵を越えた」貢献だったとしたら、それを維持する意味はほとんどないと思います。

MesonビルドはPR＃311でLAPACKにパラシュートで組み込まれました。

うーん。 それが3.9.0に受け入れられた場合（概念実証としてであっても）、次のリリースで再びそれを破棄するのは少し奇妙に見えるでしょう...

私は@theraultに連絡して、彼が私たちに意見を述べることができるようにしました。これが@theraultの言うことです。 ありがとう@therault！

Open MPIはautoconf（automake、autoconf、configure、Makefiles）のみを使用します。

PaRSECとDPLASMAの場合、CMakeのみを使用し、構成に慣れているユーザーを支援するために、

configureとCMakeの両方を維持しようとした1つの主要なプロジェクトを知っています。 CMakeで機能の100％が利用可能であり、configureでサポートされる新機能がますます少なくなる状況でゆっくりと進化しました。 彼らは設定バージョンの維持をやめたと思います。

コードに対して2つのビルドシステムを維持することは困難です。理論的には、ビルドシステムは任意のコードで機能する必要があるため、2つを維持することが可能である必要があります（メンテナが同期を維持するために高いコストがかかるため、 configureは他のプロジェクトで削除され、メンテナは自分の時間ともっと良い関係があると判断しました）。 実際には、コードをビルドシステムに適合させて、物事をよりクリーンにする必要がある場合があります。 その場合、2つのビルドシステムの1つは、回避策とハックを使用して、他のビルドシステムと同じように、コードに従って動作する必要があります。

結局、CMakeまたはconfigureは、どちらもがっかりするでしょう。 私たちはプログラマー/数学者/アルゴリズムを実行しています...コンパイラーとフラグのこの組み合わせで、そのマシンでコードが正しくコンパイルされない理由を理解するために時間を費やしています。誰もそれを好きではありません。 さらに悪いことに、CMakeやautoconfを使用してそのことや他のことを行う方法を見つけようとすると、壁を越えてしまいます:)両方を使用すると、両方について不平を言うことを保証できます：）1つを維持することは確実な方法です不平を2回少なくします。

今日、私は単一の理由でCMakeに賛成です：CMakeはMakefilesの代わりにNinjaファイルを生成するのに良い仕事をします。 Ninjaは、Make -jよりも2〜3倍高速にPaRSECをコンパイルします。 さて、configure / autoconfでもNinjaファイルを生成できるかもしれませんが、試したことはありません... ninjaを試したことがなく、LAPACKにCMakeバージョンがある場合は、cmake -G Ninjaを試すことをお勧めします（マシンにNinjaをインストールした後）。 コンパイルするには、「make」ではなく、cmakeを実行したディレクトリで「ninja」を呼び出します。 あなたが見るでしょう、それは素晴らしいです:)

興味があれば、上記のconfigure-to-cmake接着スクリプトをLAPACKに提供できてうれしいです。
（明確にするために、そのスクリプトはautoconf / m4ベースではなく、 configure --with-feature=valueをcmake -DFEATURE=valueへの呼び出しに変換する単純なスクリプトですが、もう少し洗練されています）。

LAPACKはconfigureも使用していません-autoconf / automake / configureベースのシステムをcmakeと並行して維持するのはおそらく苦痛であり、autotools自体は常に「進化」し、m4マクロなどに依存しています。

CMAKEへの移行が心配です。使い方がわからないだけでなく、維持方法もわからないからです。

これがMakefilesに固執する主な理由です。

すべて：このスレッドであなたの意見を表明してください。

Mesonビルドを削除する必要があります。 誰もそれを使用しておらず、それを維持する方法も誰も知らず、元の作者は不完全なビルドを提出し、彼の変更がマージされた後に戻ってくることはありませんでした。 この号を開く前に、Mesonビルドがあることを知っていた人は何人いますか？

CMakeは、シンプルな構文と完全に構成可能なビルドを備えたポータブルビルドシステムです。 ファイル固有、コンパイラ固有、またはターゲット固有のオプションを設定できます（たとえば、 gethostname()ようなC標準ライブラリにない関数を選択的に有効にするため）。 CMakeには堅牢なオブジェクトファイル管理があります。 これにより、gitブランチを切り替えた場合でも、 makeと入力し続けてビルドを更新できます。 CMakeは、UNIXエコシステムの他の部分とうまく相互作用します。任意のプログラムを呼び出して、それらの出力に基づいて動作することができます。 たとえば、pkg-configを呼び出して他のパッケージを見つけることができます。

CMakeを初めて使用したのは2016年で、それ以来、Linux、Mac、iOS、およびAndroidシステム用のコードをx86、x86-64、armv7、およびaarch64命令セットアーキテクチャでビルドするために継続的に使用しています。 これは、すべての主要なLinuxディストリビューションと、私がアクセスできるすべてのスーパーコンピューター（Grid 5000、Jean Zay、JUWELS、GRICAD、Eagle II）で利用できます。 スーパーコンピューターには通常、古いリリースとごく最近のリリース（3.18以降）を含む複数のバージョンがあります。 私がCMakeの可用性に苦労した唯一のプラットフォームはCentOS7ですが、いつでもCMake tarballをダウンロードし、tarball内のブートストラップスクリプトを使用して、GNUMakeでのみCMakeをビルドできます。

CMakeは私のためにちょうど働きます。

他のビルドシステムでの私の経験は次のとおりです。

• Bazel：1GBのメモリを搭載したRaspberry Piで実行することは不可能な巨大なメモリを大量に消費し、すべての依存関係を構築し、すべてを静的にリンクすることを主張します
• Autotools：開発者としては経験がなく、ユーザーとしてはconfigureスクリプトは利用可能なすべてのオプションを表示できるため、非常に便利です（CMakeはcmake実行した後にのみccmakeでそれを行います一度）。

今日、私は単一の理由でCMakeに賛成です：CMakeはMakefilesの代わりにNinjaファイルを生成するのに良い仕事をします。 Ninjaは、Make -jよりも2〜3倍高速にPaRSECをコンパイルします。

素晴らしい、忍者は過去にFortranをコンパイルできませんでした。 忍者＃1265 、つまり、一部のディストリビューションではこれは機能しません（Debian9？）。

この場合、通常のmakefileの方が簡単で十分だと思います。
HPCクラスターでのソフトウェアの保守Cmakeの使用には非常に失望しています。

1. 開発者は、標準の命名スキームに従うのに苦労しており、ドキュメントを過度に読んでいるために構築に苦労しています。 すべてのパッケージは、プロジェクトに合う名前の「微調整」を行います。 したがって、非標準の命名スキームになってしまいます。 （autoconf +には少し当てはまりますが、ここではさらに標準化されています）
2. ものがcmakeで壊れたとき、それをデバッグするにはcmakeの専門家が必要です、私はまだものをデバッグするのに非常に苦労しています... :(
3. 設定ファイルを使用するのは難しい（ make.inc ）ため、ビルド時にすべてのbulild-optionsをコマンドラインで指定する必要があります。

一方、cmakeも素晴らしいことをします：

1. より簡単なウィンドウのサポート
2. 依存関係のより自動処理と他のプロジェクトのcmakeファイルの組み込み（これは素晴らしい利点です）

ただし、LAPACKの非常に単純なビルドシステムの場合、良い点と悪い点はないと思います。 現在のビルドシステムは何十年も機能しており、人々はそれに慣れています。
また、高速並列ビルドの場合、これを現在のmakefileシステムに簡単に追加できます...

私は実際には好みを持っていませんが、より多くがサポートされている場合、どのビルドシステムによってどのオプションがサポートされているかは絶対に明確である必要が

私はあなたが@langouであるのと同じような状況にいるように感じます。

私はcmakeを知りません。 すべての構成がすでに配置されていて、travis構成を開き、実行する行をコピーして貼り付けることで、このプロジェクトでのみ使用できました。 経験が浅いからといって、そうは思いません。 Makefileは少し魔法が少なく、レベルが低く感じられます。 それは、このプロジェクトに取り組む傾向のある種類の人々に共鳴する可能性が高いものです。
純粋に個人的な使用の場合は、gmakeを使い続けますが、現在cmakeでのみ使用できるすべての機能をMakefileに配置する必要があります。 特に共有ライブラリターゲット。

ただし、cmakeが提供するように見えるすべての優れた機能を無視することはできません。 最終的には、cmakeまたはgmakeのどちらでも問題ないと思います。 1つ選ぶだけです。

私は外部の声ですが、 conda-forgeでlapackを維持するのを手伝う人として、ビルドシステムをCMakeにすることには、いくつかの利点があります（ハッキーが少ない、ネイティブWindowsのサポートなど）。

CMake構文に慣れるには多少時間がかかりますが、私の印象では、これは、多くの厄介なビルドの問題を正常に解決/抽象化した、十分に保守され、十分に文書化されたソフトウェアです。 私は他のライブラリのパッケージ化にも関わっており、（主観的に）CMakeへの移行がますます見られます。

外部からのちょうど別のデータポイント。 かなりのC / C ++ビルドを伴う作業では、CMakeに苦労しすぎた後、Mesonに移行します。 それに関する問題の長いリストは他の場所で十分に文書化されているので、私はそれらをスキップします。

SciPyプロジェクトでは、Python distutilsが廃止されているため、ある時点でCMakeまたはMesonの使用も試みます。

私は、3つのビルドシステムを維持することが、メンテナの不整合や余分な作業につながることに同意します。 ただし、上記のコメントに基づいて、そして私の意見では、各ユーザーはコードを構築する独自の方法を持っています。 特に、 @ theraultのコメントに同意し

私たちはプログラマー/数学者/アルゴリズムを実行しています...コンパイラーとフラグのこの組み合わせで、そのマシンでコードが正しくコンパイルされない理由を理解するために時間を費やしています。誰もそれを好きではありません。 さらに悪いことに、CMakeやautoconfを使用してそのことや他のことを行う方法を見つけようとすると、壁を越えてしまいます:)両方を使用すると、両方について不平を言うことを保証できます：）1つを維持することは確実な方法です不平を2回少なくします。

複数のビルドシステムの問題を回避するための1つのアイデアは、次のとおりです。

• サポートされているすべてのビルドシステムをカバーするように、CIでさらに構成を作成します。 このようにして、すべてのビルドシステムが基本機能で動作することを保証します。
• すべてを提示し、READMEでビルドシステムの1つを使用することを提案します。 例：_We共有および静的ライブラリを構築する必要がある場合はマーティン・frbg、@クリストフ・conrads @で述べたように、..._、CMakeの使用を示唆しており、このスレッドで@thijssteel。 （リポジトリにMesonビルドシステムがあることを知りませんでした。READMEに追加するか、このオプションの保守を停止する必要があると思います。）

私が理解している限り、 recursiveフラグの問題は、テストルーチンxeigtstz （https://github.com/Reference-LAPACK/lapack/issues/335#を参照）。 issuecomment-485021575）。 この問題が修正されたとき、私はどちらかを決定するだろうと思います

1. デフォルトのCMake構成にフラグを追加し、それ以外の場所にフラグを追加するか、
2. make.inc.*ファイルからフラグを削除します。

-frecursiveわずかな誤解-これはマルチスレッドコードが正しく機能するために必要なので、一般的にビルドファイルから削除しないでください。 ただし、副作用として、ローカル配列がスタックに配置されます。これは、xeigtstzの場合は非常に大きくなります。 TESTING / EIG Makefileからこのオプションを（のみ）削除すると、単純なケースでは役立つように見えますが、 `-fopenmp 'を使用してコンパイルすると暗示されるように見えるため、これは、そのテストの異常に大きなスタック制限要件に対する一般的な解決策ではありません。

だからここに理由があります。
LAPACKが「シンプルな」ライブラリであることに同意します。makeシステムを持っているだけで十分であり、長い間それで十分でした。
しかし、しかし..ウィンドウがあります..そしてウィンドウのためだけに、私たちはcmakeを持って来なければなりませんでした。 もともとはCMakeの人たちが設定に取り組んでいましたが、今は自分たちでやっていると思いますし、 @ langouのように、実際にはマスターしていません。
現在、LAPACKに基づくほとんどのソフトウェアはCmakeを使用しており、ユーザーのフィードバックから、彼らはそれを気に入っていることがわかります。

したがって、ビルドシステムを1つ選択する必要がある場合、これはCmakeである必要があります...現在は残念ながら、将来は幸いです。

私の投票： @abouteillerと@ @ theraultのアドバイス

現在、LAPACKに基づくほとんどのソフトウェアはCmakeを使用しており、ユーザーのフィードバックから、彼らはそれを気に入っていることがわかります。

私はこの問題を開き、ビルドシステムを1つだけにすることを提案しました。 私の想定では、MakefileとCMakeのスキルはほぼ均等に分散されています。 私が間違っている場合は訂正してください。しかし、私の印象では、これは通常のLAPACK寄稿者の間では当てはまりません。Makefileは人気があり、CMakeの知識はあまり強くないようです。 さらに、2日間の議論の後、 -frecursiveフラグは、CMakeとMakefileビルドの唯一の違いであり、TravisCIではCMakeのみが使用されているという事実が明らかになっています。 コアコントリビューターを追い払った場合にユーザーを満足させる1つのビルドシステムを強制することは意味がありません。

（誰が定期的な寄稿者であるかについての私の判断は、受け入れられたプルリクエストの最初の5ページを見ることに基づいています。）

同意します。ところで、再帰フラグはデフォルトのCMakeおよびMakefile構成で＃492になっています。 したがって、TravisCIにMakefileビルドを含める必要があると思います。

PR＃500は、ここで報告されているMakefileとCMakeビルドシステム間の不整合を軽減します。 https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment-788164244を参照して

こんにちは@ilayn。 Meson / CMake / Makefileの情報をありがとう。 外部からのフィードバックがあり、他のプロジェクトが何をしているかについての情報を得るのは素晴らしいことです。 3つのシステムすべてをサポートすることはできず、現時点ではCMakeとMakefileを使用することをお勧めします。そのため、Mesonを廃止する可能性があります。 Mesonを使用しないと言っているわけではありませんが、今のところ、Mesonを維持するためのリソースがありません。 これは私の意見です。 Mesonを廃止するPRをまもなく提出すると思います。 ジュリアン。