Why so?
On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) Certain utilities like gdb will not run because System Integrity Protection disallows them. In theory, we can sign gdb through a somewhat circuitous series of steps, except that this doesn't work if we want to ssh into the box. This requires turning off SIP, modifying some files, and then turning SIP back on. Technically, it's all possible, but it's one series of aggravations after another. Developing on a platform should not be this difficult.
I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.).
Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake.
And then you have to deal with things such as VC's standard library not having getopt, etc.
For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.
Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS.
Also, Visual Studio has its own package manager with tons of libraries and tools.
Of course, much of changes now with Windows Subsystem for Linux.
Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches.
As a quick note, thank god for the Homebrew crew as that does make things much nicer.
As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.
Kind of annoying that Intel's Fortran compiler on Windows is the only commonly-used one that doesn't at least allow you to ask for gfortran-compatible mangling. Hopefully if the PGI LLVM Fortran front-end ever gets released it'll be another option (fingers crossed that it uses gfortran compatible mangling so life is simpler).
It is also possible to link gfortran compiled dll's with C and C++ in Visual Studio. A few years ago I even called a gfortran dll from C# using p-invoke with no particular problem.
Agree, this is why I've mentioned that you can use Fortran code compiled as a DLL with gfortran (open source) from Visual Studio in C, C++ and C# projects.
I'm sure they'd appreciate help.
A funny footnote to that article is now with Windows 10 and the ucrt, Windows is "a Microsoft Visual C/C++ Run-Time delivery channel" once again.
My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operating system and no changes ever how things look or work.
That pretty much limits you to Debian unstable... Or Windows, if forcibly upgrading counts as "rolling."
But wouldn't a rolling release be the exact opposite of what you'd want if you want no changes, ever? And if that's the case, just don't upgrade macOS until Xcode forces you to, that usually gives you a few years. I stayed on Snow Leopard for years until Apple put a gun to my head, but Mavericks and Yosemite gave me no problems; everything worked just like it did before. (I still miss Snow Leopard, though...)
Typically, changes in rolling releases are easier to deal with. At any time, the change is smaller, so you don't have to be overwhelmed by a large number of changes all over the place, as is sometimes the case with versioned releases; and the changes are fresher, so your inputs to the developers who made the change are easier to apply.
Hence my remark, the original workstation where twm was created is good enough.