Add Python to the list. If you're using 64 bit versions it becomes a nightmare. I do have to remark that finally Microsoft did something about it and released a special version of MSVC to solve part of the issue, but for some modules it still is challenging to get everything working correctly.

I only had that experience with projects that use autoconf for build configuration, usually these are tied very closely to UNIX-like platforms. Most libs that use cmake to setup the build files can be integrated well on Windows (most likely because the author choose cmake exactly for this reason to be easily usable across platforms). But that's more of a problem of Linux isolationism than Windows' fault (basically the modern version of the bad old days when everyone was on Windows and all you got to build a project from source was a bunch of Visual Studio project files).

But even with cmake there's no standard place for third-party libraries to be installed on Windows. There's no /usr/lib and /usr/include analogue. So if I'm writing software that uses a third-party library I either have to bundle it into my source tree or hope there's an installer for it, burn the default installation location into the build system, and hope the user compiling my code has not overridden the default location. (I know some installers like Qt will make a system environment variable to say where their libraries are, but that's not particularly nice if everything did that.)

In my case I needed libapr, and as far as I can tell there is no installer for it, so I wound up just saying "drop a compiled copy of libapr into this location in the source tree" into the build instructions since I did not want to redistribute it with my source.

So yes, I dearly wish for something like a working pkgconfig on Windows.

> There's no /usr/lib and /usr/include analogue

I would argue that it is a good thing to not rely on /usr/lib or /usr/include even on Unix. It is a pain for when a dev who is jumping on the team specially when the dependencies are not documented. The make-dependency error-install-make cycle is very annoying.

I usually try hard to not link against 'installed' libs but instead directly compile external dependencies from source as part of my project. That way I don't need to have different libs for different build configs or VStudio versions. CMake can import sources from locations outside your source tree, and these source locations can be relative to your project (e.g. on the same directory level). That way you don't need any global system settings, or centralized locations, everything can be relative to your project. I actually prefer this also on OSX or Linux.