MSYS2のデフォルトのシェル(bash)は、環境変数MSYSTEM
も設定する3つのランチャーから選択して起動できます。具体的には:
msys2_Shell.bat
はMSYS
に設定しますmingw64_Shell.bat
はMINGW64
に設定し、mingw32_Shell.bat
はMINGW32
に設定します。シェルのプロンプトとは別に、目に見える違いは次のとおりです。
$MSYSTEM
がエクスポートされています。uname
出力は$MSYSTEM
に基づいています。$MSYSTEM
がMINGW*
の場合、/mingw*/bin
は$PATH
の最初のパスです。/usr/bin/gcc
、/mingw64/bin/gcc
、/mingw32/bin/gcc
があるとすると、$MSYSTEM
の設定値の実用的な結果は、異なるコンパイラーを使用して異なるバイナリー(POSIXまたはネイティブ)を生成することです。 32/64)。
$MSYSTEM
値によって決定される他の重要な違いは何ですか?pacman
はサブシステムの影響を受けますか?以下は、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
はサブシステムの影響を受けますか?
はい。
3つの選択肢の背後にある意図は、2つの異なる開発環境のオプションを提供することでした。
MinGW:ネイティブWindowsアプリケーションの開発を目的としています。これはさらに次のように分類されます。
これは、エンドユーザー開発を行う場所と考えてください。 MSYS2環境自体の内部では通常実行されないソフトウェア。
MSYS:FHSスタイルのファイルシステムのネーミングでposix-y環境で動作するアプリケーションを構築することを目的としています。これは、実際にMsys2内で実行されているツールの開発を行う場所と考えてください。または、Cygwinと同じように考えることができます。
この問題の詳細については、MSYS2 sourceforgeフォーラムの this thread を参照してください。
/etc/profile
を確認する必要があります(これは GitHubのこのファイル から取得されます)。 MSYSTEM
が以下に影響することがわかります。
PATH
PKG_CONFIG_PATH
ACLOCAL_PATH
MANPATH
MINGW_MOUNT_POINT
また、MSYSTEM
に基づいて追加の変数を設定するスクリプトである/etc/profile/msystem
を追加する pull request もあります。