I've got a more serious blog post in the pipelines. However, right now, I just want to take a moment and complain about a mess I came across.
So, it's been a while since I have last programmed in C or C++. In fact, I have never done any real C programming and it's been over half a decade since I was serious about a C++ project. I have recently done some Arduino work, but there you don't really have to worry about the compiler yourself, so it's not relevant here. And because the compiler is what I am talking about here, so C++ and C can be thrown on the same pile, as I use the GNU Compiler Collection (gcc) for both.
Man, the gcc for windows situation is a mess...
So, there has always been MinGW and Cygwin. Cygwin is a whole POSIX emulation stack. Programs had to be compiled specifically for running in the Cygwin environment, but it was easy to do this for any linux program. Such programs would always need at least the Cygwin compatibility layer dll to run. Many people also just use Cygwin for a linux-like environment (since the GNU tools provide what many people consider "linux-likeness") on Windows without using the compiler. I've always used some version of msys for this, but I'll get to what that is in a moment.
The other option was MinGW. Rather than a full compatibility layer, it just aims to provide a compiler that can compile things natively for Windows. You will need to talk to the Windows APIs just like you would when using a different c----ompiler like Visual C++. It's just a way to get gcc to compile for Windows.
However, MinGW was married to MSYS. MSYS was forked from Cygwin at some point, but it did away with its compatibility layer. Instead, it used MinGW to compile some of the core GNU utils for native windows. This also gives you sort of a linux-like system on Windows. This was necessary to run mingw and meant that msys was a part of the mingw project. However, you could also use mingw to cross-compile from linux to windows, in which case you didn't need msys.
Unfortunately, mingw only supported 32 bit applications. When I say around the time when this started being an issue, I mean during the days of Windows XP x64 and Windows Vista and 7, which had had 32 bit and 64 bit versions which were both used (yes, a lot has changed since then). So around that time, there was a company that developed a mingw version for 64 bit application in house. At some point, it donated this code to open source and it was tried to merge it with the mingw project. However, this project suspected there were some licensing issues and a rift occurred. A second project started, called mingw-w64. It also had its own msys version (I think) and if I remember correctly it could actually compile for 32 bit and 64 bit applications.
During this time, mingw had a bit of an installer problem. The person who had been maintaining the installer left the project and basically nobody wanted to work with the same installer building tool. This led to the installer version they provided to be horribly out of date. You had to mess around with packages to get a more recent version. They were rather hostile to help offered by volunteers from outside the project, demanding that such help would be maintained by the same person indefinitely. There was some work on a new system inspired by the apt-get interface, but there was no temporary solution in the mean time. This system got done eventually, but by then the project had suffered greatly already.
Enter git. Git is not a compiler. However, it relies on GNU tools to do its job, so it needed some of them to be able to run on Windows. So, they created their own version of msys (msysgit) which makes them relevant to this story. At some point I switched from mingw's msys to msysgit for my "proper command line" needs and since then I haven't really kept up with the mingw project.
That is, until now. I want to make a utility that uses I2C on linux and my best bet seems to be C. So, I went to look for a compiler. What I really need is a cross-compiler from Windows to ARM linux, or perhaps an ARM compiler on the device itself or maybe even a cross-compiler from x64 linux to ARM linux to run from a (virtual or other) linux installation, but I ended up looking at mingw first. I had a very old version installed as part of the haskell project (oh joy!) and a slightly more recent version from my C++ development days. So, I started looking into the mingw situation.
The mingw project seems to have bled to death. Their site is still online, but nothing seems to have happened for them in over three years. In a way, this is logical. They were already struggling in those days and today you don't really have to bother with 32 bit applications anymore as 64 bit is commonplace enough. mingw-w64 is still alive and kicking and it seams to be the way to go. However, there's also msys2.
The project page describes them as a rewrite of msys and they mention the reason for their existence is the fact that the original msys wasn't able to keep up with Cygwin. However, what I think is one of their main accomplishments is that they divorced from mingw. Don't get me wrong, they are still seeing each other, just not living together anymore. The tools are still built with a mingw version (I think the w64 version) and it is still an important way to run mingw, providing support for both (the outdated) mingw and mingw-w64 out of the box. However, they are just not the same project anymore, so the coupling is not as tight anymore (i.e. they are not wearing rings and they are allowed to see other people).
The new msys2 also does away with the apt-get inspired installer in favor of a new port of Arch's package manager, pacman. Oh, and they apparently don't play well with msysgit or the original msys. Things never get simple, do they.
Confused yet? I definitely am!
Edit: It seems there still was an important bit I missed. The more recent version of git for windows (incidentally, called Git for Windows rather than msysgit as the older versions were called) don't actually use their own msysgit anymore. Instead, they are already packaging msys2, which means that I have already been using it for quite some time...
No comments:
Post a Comment