6 ms·

Msys2 is amazing, and everyone should know about and support this project.

by analognoise 11y ago

aidenn0 11y ago
I had never heard of it before this. Does it have updated cygwin libraries? The ones in msys are really old and crufty.
- lqdc13 11y ago
  It has new libs like new GCC etc. However, it's not nearly as usable as arch. Things like vim configs have differences.
  - striking 11y ago
    You can always update the configuration to better match Arch's and file a pull request against it. Here's the link to the msys2-packages repo for Vim, for example: https://github.com/Alexpux/MSYS2-packages/tree/master/vim https://github.com/Alexpux/MSYS2-packages/tree/master/vim Same build system and everything, it just requires some finagling and copying of the PKGBUILDs.
    - RayDonnelly 11y ago
      Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.
  - deleted 11y ago
    [deleted]
  - jsmthrowaway 11y ago
    vim configs are often different per-platform anyway. I have an if mac/else block in my gvimrc, since gfn, for example, requires "Font:hSize" on OS X and another type of font selector on Linux-based systems. Things like that are not really new.
- bjg 11y ago
  Yea, they track it pretty closely. See: https://github.com/Alexpux/Cygwin/tree/msys2-master https://github.com/Alexpux/Cygwin/tree/msys2-master
- RayDonnelly 11y ago
  Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution. We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date. Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant. Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.
  - 2bitencryption 11y ago
    Sorry for the basic questions, but the github page (and SourceForge page) aren't answering all of my beginner's questions... If Msys2 is Cygwin-derived, does that mean all packages in the Msys2-Pacman are all Cygwin packages? I.e., making this "Cygwin with Pacman as a package manager?" Does this also mean Msys2 packages can never be more current than Cygwin packages (not that this is a bad thing, but as far as I know Python3 in Cygwin is still < 3.5). Is the benefit of Msys2 that some packages could be native windows builds instead of Cygwin-dll reliant packages?
    - RayDonnelly 11y ago
      This has been answered before. No, the msys2 repo doesn't follow the Cygwin packaging versions or schedules at all. They are built from the recipes at: https://github.com/Alexpux/MSYS2-packages https://github.com/Alexpux/MSYS2-packages .. they link to msys-2.0.dll which is Cygwin derived and are thus GPLed and exist to provide a POSIX-y shell and build tools to allow building: https://github.com/Alexpux/MINGW-packages https://github.com/Alexpux/MINGW-packages .. which are full of native Windows software under various licenses.
      - e12e 11y ago
        Is there some more documentation on how msys2 relates to mingw somewhere? I recently came across msys2 when half-heartedly trying to compile Darktable[1] for windows 10. As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows. Both have their place -- but I'd be really happy if something akin to msys2 was available more like mingw -- so I could use the (now finally quite usable) standard windows command line along with (hopefully) MS compilers and have some hope of compiling stuff that uses automake etc. As far as I can figure out, msys2 doesn't (try to) help with that? It's more like a GNU chroot that runs under windows? In which case most/many use-cases might be better served with a vm under VirtualBox/hyper-v[2] and/or a true "native" windows port? Not meant as criticism of the project, I'm just trying to figure out if I've understood the focus of msys2 correctly. Finally, for those wishing for "more GNU" on windows, one of the most pleasant discoveries I've made, is the scoop package manager: http://scoop.sh/ http://scoop.sh/ [1] http://www.darktable.org/install/ http://www.darktable.org/install/ [2] Especially if/when Vagrant works out of the box with hyper-v -- I'm not quite clear on the current status, but looks like it's been enabled and is included in default Vagrant now: https://www.vagrantup.com/docs/hyperv/index.html https://www.vagrantup.com/docs/hyperv/index.html
- pippy 11y ago
  One thing I do like about msys over cygwin is that compiled binaries don't have a dependency on a dll. If msys2 is using cygwin libraries, does it have the same dependency?
  - aidenn0 11y ago
    You're wrong about that; mingw doesn't require dependency on the dll, msys does.
    - Benjamin_Dobell 11y ago
      Huh? No. Cygwin depends on a DLL. Mingw does not. Msys is just a user-land set of tools.
      - rossy 11y ago
        Yep, but those tools rely on a DLL (msys-1.0.dll or msys-2.0.dll,) which is Cygwin by another name. MSYS is not MinGW. Programs like Bash will never run under MinGW because they rely on things like fork(), which are only provided by Unix, Cygwin, or a Cygwin fork like MSYS.
        RayDonnelly 11y ago
        .. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows form. The same is true for some specific environment variables.
      - aidenn0 11y ago
        I thought some of the msys tools relied on a cygwin-like DLL for fork().

Msys2 is amazing, and everyone should know about and support this project.

aidenn0 11y ago

I had never heard of it before this. Does it have updated cygwin libraries? The ones in msys are really old and crufty.

lqdc13 11y ago
It has new libs like new GCC etc. However, it's not nearly as usable as arch. Things like vim configs have differences.
- striking 11y ago
  You can always update the configuration to better match Arch's and file a pull request against it. Here's the link to the msys2-packages repo for Vim, for example: https://github.com/Alexpux/MSYS2-packages/tree/master/vim https://github.com/Alexpux/MSYS2-packages/tree/master/vim Same build system and everything, it just requires some finagling and copying of the PKGBUILDs.
  - RayDonnelly 11y ago
    Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.
- deleted 11y ago
  [deleted]
- jsmthrowaway 11y ago
  vim configs are often different per-platform anyway. I have an if mac/else block in my gvimrc, since gfn, for example, requires "Font:hSize" on OS X and another type of font selector on Linux-based systems. Things like that are not really new.
bjg 11y ago
Yea, they track it pretty closely. See: https://github.com/Alexpux/Cygwin/tree/msys2-master https://github.com/Alexpux/Cygwin/tree/msys2-master
RayDonnelly 11y ago
Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution. We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date. Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant. Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.
- 2bitencryption 11y ago
  Sorry for the basic questions, but the github page (and SourceForge page) aren't answering all of my beginner's questions... If Msys2 is Cygwin-derived, does that mean all packages in the Msys2-Pacman are all Cygwin packages? I.e., making this "Cygwin with Pacman as a package manager?" Does this also mean Msys2 packages can never be more current than Cygwin packages (not that this is a bad thing, but as far as I know Python3 in Cygwin is still < 3.5). Is the benefit of Msys2 that some packages could be native windows builds instead of Cygwin-dll reliant packages?
  - RayDonnelly 11y ago
    This has been answered before. No, the msys2 repo doesn't follow the Cygwin packaging versions or schedules at all. They are built from the recipes at: https://github.com/Alexpux/MSYS2-packages https://github.com/Alexpux/MSYS2-packages .. they link to msys-2.0.dll which is Cygwin derived and are thus GPLed and exist to provide a POSIX-y shell and build tools to allow building: https://github.com/Alexpux/MINGW-packages https://github.com/Alexpux/MINGW-packages .. which are full of native Windows software under various licenses.
    - e12e 11y ago
      Is there some more documentation on how msys2 relates to mingw somewhere? I recently came across msys2 when half-heartedly trying to compile Darktable[1] for windows 10. As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows. Both have their place -- but I'd be really happy if something akin to msys2 was available more like mingw -- so I could use the (now finally quite usable) standard windows command line along with (hopefully) MS compilers and have some hope of compiling stuff that uses automake etc. As far as I can figure out, msys2 doesn't (try to) help with that? It's more like a GNU chroot that runs under windows? In which case most/many use-cases might be better served with a vm under VirtualBox/hyper-v[2] and/or a true "native" windows port? Not meant as criticism of the project, I'm just trying to figure out if I've understood the focus of msys2 correctly. Finally, for those wishing for "more GNU" on windows, one of the most pleasant discoveries I've made, is the scoop package manager: http://scoop.sh/ http://scoop.sh/ [1] http://www.darktable.org/install/ http://www.darktable.org/install/ [2] Especially if/when Vagrant works out of the box with hyper-v -- I'm not quite clear on the current status, but looks like it's been enabled and is included in default Vagrant now: https://www.vagrantup.com/docs/hyperv/index.html https://www.vagrantup.com/docs/hyperv/index.html
pippy 11y ago
One thing I do like about msys over cygwin is that compiled binaries don't have a dependency on a dll. If msys2 is using cygwin libraries, does it have the same dependency?
- aidenn0 11y ago
  You're wrong about that; mingw doesn't require dependency on the dll, msys does.
  - Benjamin_Dobell 11y ago
    Huh? No. Cygwin depends on a DLL. Mingw does not. Msys is just a user-land set of tools.
    - rossy 11y ago
      Yep, but those tools rely on a DLL (msys-1.0.dll or msys-2.0.dll,) which is Cygwin by another name. MSYS is not MinGW. Programs like Bash will never run under MinGW because they rely on things like fork(), which are only provided by Unix, Cygwin, or a Cygwin fork like MSYS.
      - RayDonnelly 11y ago
        .. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows form. The same is true for some specific environment variables.
    - aidenn0 11y ago
      I thought some of the msys tools relied on a cygwin-like DLL for fork().