web-dev-qa-db-fra.com

MSYS vs. MinGW: variables d'environnement internes

Le shell par défaut MSYS2 (bash) peut être démarré en choisissant parmi trois lanceurs, qui définissent également la variable d'environnement MSYSTEM. Plus précisément:

  1. msys2_Shell.bat le définit sur MSYS
  2. mingw64_Shell.bat le définit sur MINGW64 et
  3. mingw32_Shell.bat le définit sur MINGW32.

Hormis l'invite des obus, les différences visibles sont:

  • Il existe une variable Shell équivalente $MSYSTEM exporté;
  • uname la sortie est basée sur $MSYSTEM;
  • Quand $MSYSTEM est MINGW*, /mingw*/bin est le premier chemin dans $PATH.

En supposant que nous avons /usr/bin/gcc, /mingw64/bin/gcc, /mingw32/bin/gcc, une conséquence sensible de la valeur définie de $MSYSTEM est que nous utiliserons un compilateur différent générant un binaire différent (POSIX ou natif 32/64).

  • Quelles sont les autres différences importantes déterminées par $MSYSTEM valeur?
  • Existe-t-il des fichiers binaires qui utilisent spécifiquement cette variable?
  • pacman est-il affecté par le sous-système?
mingwmsysmingw-w64msys2
19
antonio

Ce qui suit est extrait d'un post par Ray Donnelly, un contributeur MinGW-w64. Il éclaire le sujet et est un préambule essentiel à ma question.

Il existe 3 systèmes, MSYS2 et les systèmes Windows natifs 32 bits et 64 bits. Chaque système possède son propre référentiel de packages logiciels dans la distribution MSYS2. [...] c'est une distinction importante entre eux. MSYS2 implémente un espace de noms de système de fichiers POSIX-y FHS et c'est très important pour beaucoup de choses.
[...] Les systèmes MinGW-w64 32 bits et 64 bits sont des logiciels Windows natifs qui sont enracinés respectivement dans/mingw32 et/mingw64. Ce n'est pas comme si nous avions remplacé chaque appel d'API Linux nous-mêmes; la plupart des projets en amont font ce travail pour nous car ils fournissent déjà des ports Windows, mais oui, parfois nous devons le faire. Nous ajoutons également des correctifs de relocalisation spéciaux à de nombreux logiciels afin que vous soyez libre d'installer la racine tout (par exemple C:\msys64) où vous le souhaitez. Le logiciel MSYS2 n'a pas besoin de ces correctifs (car l'emplacement Windows natif est un détail d'installation caché), mais le logiciel MinGW-w64 en a souvent besoin.
[F] du point de vue de l'utilisateur final, il n'y a que 2 systèmes, MSYS2 et Windows natif XX bits, et oui, certains packages existent pour ces deux systèmes. Plus précisément, MSYS2 existe pour exécuter les outils de développement nécessaires à la création de logiciels Windows natifs, donc si un système de construction a besoin d'une version MSYS2 de Python ou Perl pour fonctionner correctement (car il suppose FHS ou autre), nous devons alors fournir ces packages. . Nous n'ajoutons jamais de packages MSYS2 sans nous assurer qu'ils sont nécessaires. Si vous ne savez pas que vous avez besoin de la version MSYS2 de quelque chose, installez plutôt la version native Windows appropriée.
Un exemple de cas où vous aurez besoin de MSYS2 Python est si vous essayez d'utiliser les outils de repo de Google. Cela est dû au fait que repo utilise le module fcntl Python et que ce module existe uniquement sur les systèmes POSIX-y. IMHO Python fait un mauvais travail d'abstraction des OS ici et c'est une chose fondamentale qu'un langage de script devrait faire, et fcntl (et pyWin32) ne devrait pas exister, mais je ne suis pas le patron de Python.
Heureusement, Pacman a une gestion des dépendances et installera les éléments nécessaires pour tous les packages qui vous intéressent réellement.
Les outils automatiques GNU ne fonctionneront jamais correctement que via un système compatible FHS avec un shell POSIX, et cela conduit naturellement à d'autres outils qui doivent exister dans le même espace de noms de système de fichiers, tels que make, Perl, m4, bison, flex, etc. etc.

Compte tenu de la publication de Ray Donnelly, ce qui constitue un système est d'abord et avant tout la variable PATH, car, selon les priorités du répertoire, les outils de dépôt de Google seront construits avec des packages MSYS2 ou MinGW. En fait, le script Shell, qui bascule entre les shells MSYS2 et MinGW, exporte la variable d'environnement MSYSTEM avec son argument mingw32|mingw64|msys Et les sources /etc/profile. Ce dernier, à son tour, définit le PATH en fonction de la valeur de MSYSTEM. En gros pour MSYS2, le PATH est /usr/local/bin:/usr/bin:/bin, Tandis que pour MinGW 64 c'est /mingw64/bin:/usr/local/bin:/usr/bin:/bin, Donc exécuter les compilateurs gcc exécutera MSYS2 ou MinGW en conséquence . Il existe d'autres env mineurs. les variables aussi, par exemple MANPATH pour lire les manuels appropriés, une fois que les binaires appropriés sont appelés, ou PKG_CONFIG_PATH pour lire les fichiers lib appropriés, lors de la construction.

En ce qui concerne, pacman il n'est pas totalement vrai qu'il ne soit pas affecté, comme dans le commentaire de @David Grayson. MSYS2 wiki affirme vaguement que:

Utilisez le shell msys2 pour exécuter pacman, makepkg, makepkg-mingw et pour créer des logiciels dépendants de POSIX que vous n'avez pas l'intention de distribuer. Utilisez des shells mingw pour créer des logiciels natifs et d'autres tâches.

Ray Donnelly clarifie à nouveau les choses dans un autre post :

De manière générale, vous pouvez utiliser n'importe quel shell pour pacman, mais vous pouvez rencontrer des problèmes en utilisant des shells mingw où, selon les packages que vous avez installés dans/mingw32 ou/mingw64, les scripts de post-installation des packages (qui sont des scripts bash arbitraires) peut finir par exécuter une variante inattendue mingw-w64 d'un programme. Un exemple concret de cela serait "sed". Ainsi, l'exécution de pacman à partir de msys2_Shell.bat évite une classe de problèmes potentiels (bien que nous essayions de résoudre tous ceux qui sont signalés de toute façon).

Résumant:

Quelles sont les autres différences significatives déterminées par la valeur de $MSYSTEM?
Les différences significatives immédiates concernent les valeurs associées des variables de chemin identifiées par @David Grayson.

Y a-t-il des binaires qui font un usage spécifique de cette variable?
Il semble sûr de dire qu'il n'y a pas de lecture binaire spécifique directement $MSYSTEM, Mais beaucoup de logiciels utilisent/lisent les variables de chemin ci-dessus basées sur $MSYSTEM.

pacman est-il affecté par le sous-système?
Oui.

16
antonio

L'intention derrière les trois choix était de vous donner l'option de deux environnements de développement différents:

  1. MinGW: destiné au développement d'applications natives Windows. Ceci est encore divisé en:

    • Mingw32 pour produire des exécutables 32 bits, et bien sûr
    • Mingw64 pour produire des exécutables 64 bits

    Considérez ceci comme l'endroit où vous ferez votre développement d'utilisateur final. Logiciels qui ne seront normalement pas exécutés à l'intérieur de l'environnement MSYS2 lui-même.

  2. MSYS: destiné à créer des applications qui fonctionneront dans un environnement posix-y avec un nom de système de fichiers de style FHS. Considérez ceci comme l'endroit où vous ferez le développement des outils qui s'exécutent réellement dans Msys2. Ou, vous pouvez penser à cela comme vous le feriez pour Cygwin.

Vous pouvez obtenir plus d'informations à ce sujet dans ce fil sur le forum sourceforge MSYS2.

10
Kurt Fitzner

Vous devriez regarder dans /etc/profile (qui vient de ce fichier sur GitHub ). Là, vous pouvez voir que MSYSTEM affecte:

  • PATH
  • PKG_CONFIG_PATH
  • ACLOCAL_PATH
  • MANPATH
  • MINGW_MOUNT_POINT

De plus, il y a pull request qui ajoute /etc/profile/msystem, qui serait un script qui définit des variables supplémentaires basées sur MSYSTEM.

3
David Grayson