web-dev-qa-db-ja.com

MSYSとMinGW:内部環境変数

MSYS2のデフォルトのシェル(bash)は、環境変数MSYSTEMも設定する3つのランチャーから選択して起動できます。具体的には:

  1. msys2_Shell.batMSYSに設定します
  2. mingw64_Shell.batMINGW64に設定し、
  3. mingw32_Shell.batMINGW32に設定します。

シェルのプロンプトとは別に、目に見える違いは次のとおりです。

  • 同等のシェル変数$MSYSTEMがエクスポートされています。
  • uname出力は$MSYSTEMに基づいています。
  • $MSYSTEMMINGW*の場合、/mingw*/bin$PATHの最初のパスです。

/usr/bin/gcc/mingw64/bin/gcc/mingw32/bin/gccがあるとすると、$MSYSTEMの設定値の実用的な結果は、異なるコンパイラーを使用して異なるバイナリー(POSIXまたはネイティブ)を生成することです。 32/64)。

  • $MSYSTEM値によって決定される他の重要な違いは何ですか?
  • この変数を特定の方法で使用するバイナリはありますか?
  • pacmanはサブシステムの影響を受けますか?
19
antonio

以下は、MinGW-w64の貢献者であるRay Donnellyが post から抽出したものです。それは主題について啓発し、私の質問の本質的な前文です。

MSYS2、32ビットおよび64ビットのネイティブWindowsシステムの3つのシステムがあります。各システムには、MSYS2ディストリビューションのソフトウェアパッケージの独自のリポジトリがあります。 [...]それはそれらの間の重要な違いです。 MSYS2はPOSIX-y FHSファイルシステム名前空間を実装しており、それは多くのことにとって非常に重要です。
[...] MinGW-w64 32ビットおよび64ビットシステムは、それぞれ/ mingw32および/ mingw64をルートとするネイティブWindowsソフトウェアです。すべてのLinux API呼び出しを自分たちで置き換えたわけではありません。アップストリームプロジェクトのほとんどは、Windowsポートを既に提供しているため、この作業を行っていますが、そうする必要がある場合もあります。また、多くのソフトウェアに特別な再配置パッチを追加して、好きな場所にルート全体(例:C:\ msys64)を自由にインストールできるようにします。 MSYS2ソフトウェアはこれらのパッチを必要としません(ネイティブWindowsの場所は非表示のインストール詳細であるため)が、MinGW-w64ソフトウェアはしばしば必要です。
[F]エンドユーザーの視点から、MSYS2とXXビットネイティブWindowsの2つのシステムしかありません。そうです。これらのシステムの両方にいくつかのパッケージが存在します。具体的には、MSYS2はネイティブWindowsソフトウェアのビルドに必要な開発ツールを実行するために存在するため、ビルドシステムが正しく動作するためにMSYS2バージョンPythonまたはPerlが必要な場合(FHSなどを想定しているため))、これらのパッケージを提供する必要があります。MSYS2パッケージが必要かどうかを確認せずにMSYS2パッケージを追加することはありません。MSYS2バージョンが必要かどうかわからない場合は、代わりに適切なネイティブWindowsをインストールしてください。
MSYS2が必要になる場合の例Pythonは、Googleのリポジトリツールを使用しようとした場合です。これは、リポジトリがfcntl PythonモジュールとそのモジュールはPOSIX-yシステムにのみ存在します。IMHOPythonは、ここでOSを抽象化するという悪い仕事をしています。これは、スクリプト言語が行うべき基本的なことであり、fcntl(およびpyWin32 )存在すべきではありませんが、私はPythonのボスではありません。
幸いにも、パックマンには依存関係の管理があり、実際に興味のあるパッケージに必要なものをインストールします。
GNU Autotoolsは、POSIXシェルを備えたFHS準拠システムを除いて、うまく機能しないため、make、Perl、m4、bison、flexなどの他のツールが同じファイルシステムの名前空間に存在する必要があります。等.

Ray Donnellyの投稿を踏まえると、システムの構成要素は何よりもまずPATH変数です。これは、ディレクトリの優先順位に応じて、GoogleのリポジトリツールがMSYS2またはMinGWパッケージで構築されるためです。実際、MSYS2シェルとMinGWシェルを切り替えるShellスクリプトは、環境変数MSYSTEMを引数mingw32|mingw64|msysとソース/etc/profileでエクスポートします。後者は、PATHの値に基づいてMSYSTEMを設定します。概して、MSYS2の場合、PATH/usr/local/bin:/usr/bin:/binですが、MinGW 64の場合は/mingw64/bin:/usr/local/bin:/usr/bin:/binであるため、gccコンパイラを実行すると、それに応じてMSYS2またはMinGWバージョンが実行されます。他のマイナーな環境があります。変数。たとえば、適切なバイナリが呼び出されたら、適切なマニュアルを読み取るMANPATHや、ビルド時に適切なlibファイルを読み取るPKG_CONFIG_PATHなど。

@David Graysonのコメントにあるように、pacmanが影響を受けないことは完全に正しくありません。 MSYS2 wiki 漠然とそれを確認します:

Pacman、makepkg、makepkg-mingwの実行、および配布する予定のないPOSIX依存ソフトウェアの構築には、msys2シェルを使用してください。 mingwシェルを使用して、ネイティブソフトウェアやその他のタスクを構築します。

レイ・ドネリーは別の post で再び事を明らかにします:

通常、pacmanには任意のシェルを使用できますが、/ mingw32または/ mingw64にインストールしたパッケージに応じて、パッケージのポストインストールスクリプト(任意のbashスクリプト)に応じて、mingwシェルを使用すると問題が発生する可能性がありますプログラムの予期しないmingw-w64バリアントが実行される可能性があります。その具体的な例は「sed」です。そのため、msys2_Shell.batからpacmanを実行することで、潜在的な問題のクラスを回避できます(とにかく報告されている問題は修正しようとします)。

まとめ:

$MSYSTEM値によって決定される他の重要な違いは何ですか?
すぐに重要な違いは、@ David Graysonによって識別されるパス変数の関連する値です。

この変数を特定の用途で使用するバイナリはありますか?
$MSYSTEMを直接読み取る特定のバイナリはないが、$MSYSTEMに基づいて上記のパス変数を読み取る/読み取るソフトウェアはたくさんあると言っても安全だと思われます。

pacmanはサブシステムの影響を受けますか?
はい。

16
antonio

3つの選択肢の背後にある意図は、2つの異なる開発環境のオプションを提供することでした。

  1. MinGW:ネイティブWindowsアプリケーションの開発を目的としています。これはさらに次のように分類されます。

    • 32ビット実行可能ファイルを生成するためのMingw32、そしてもちろん
    • 64ビットの実行可能ファイルを生成するためのMingw64

    これは、エンドユーザー開発を行う場所と考えてください。 MSYS2環境自体の内部では通常実行されないソフトウェア。

  2. MSYS:FHSスタイルのファイルシステムのネーミングでposix-y環境で動作するアプリケーションを構築することを目的としています。これは、実際にMsys2内で実行されているツールの開発を行う場所と考えてください。または、Cygwinと同じように考えることができます。

この問題の詳細については、MSYS2 sourceforgeフォーラムの this thread を参照してください。

10
Kurt Fitzner

/etc/profileを確認する必要があります(これは GitHubのこのファイル から取得されます)。 MSYSTEMが以下に影響することがわかります。

  • PATH
  • PKG_CONFIG_PATH
  • ACLOCAL_PATH
  • MANPATH
  • MINGW_MOUNT_POINT

また、MSYSTEMに基づいて追加の変数を設定するスクリプトである/etc/profile/msystemを追加する pull request もあります。

3
David Grayson