Comment by srcmap | Hacker News Reader

Comment by srcmap | Hacker News Reader

I used to be a big VB, VC++ fan boy a long time ago. 1995 :-) Have since move on....

Tried built a few opensource apps with VS once a year for the past few years and found that I can't even compile a single Windows open source packages from github, sourceforge after weeks of trying.

The code might claim to be able to build with VS10, VS12. The dependency libraries will need completely different VS version of .xml, .proj, .sln build systems.

I challenge the PM of VS product try to build a few popular MS projs such as python, VLC, or anything in http://opensourcewindows.org/. Document the process of building the app and dependence library. Compare that to the process of try to build that same packages in Mac (with brew) or in Linux.

In Linux, for all the packages I like play with. "./configure && make" handle most of the the build in a few minutes. Even easier on Ubuntu with apt-get source/build commands. Very similar process in Mac.

Even linux kernel, I can build it easily with pretty much the same 1-2 commands for the past 20 years.

Sounds a bit cherry-picky/anecdotal to me: I regularly build open source projects using multiple versions of VS, and have created some, and it either works out of the box (because the project maintainers spent time on it - both on project system and on portable code) or else at least doesn't take weeks. Likewise on linux/mac: building from source usually works. But also not always (it is better than in 1995 though, where I'd spend hours figuring out exactly which dependency still needed building and hoping I'd find the correct patch etc. Things seem more unified now, at least to me). Also since VS2013 (possibly VS2012 as well, don't have that anymore to test) you can actually have one single project file for any version up to the latest since they all use the same format.

Don't get me wrong: configure/make is way more mature but you almost make it sound like nothing works at all with VS/msbuild which is imo often just because people don't really know how to work with it (which in turn might be because of lack of documentation/proper examples/...), or because project maintainers don't care for VS support, and/or because there is no standard dependency managment (yet? cmake does a pretty good job, vcpkg looks promising).

such as python

Wasn't that just 'msbuild path/to/python.sln'? At least for the core, might be different for other modules. But I definitely remember getting a working python.exe just by building the supplied project files.

They're sort of trying to work on this, see https://github.com/Microsoft/vcpkg. If things are strictly C++ and build using cmake, then MSVC is okay. Anything autotools or relying on inline assembly or overly complicated makefiles or scientific code that still depends on Fortran numerical libraries is a mess though. Much easier to use mingw-w64 gcc for those - bonus is you can cross compile and not have to do dev on Windows, just test the binaries.

Not to distract from your point but compiling something on Linux has always been a massive pain due to dependencies.

I often have to run configure multiple times and hunt down the correct version of whatever library it needs before re-running it and finding yet another library that it can not find (it gets even worse if you actually have the library installed but it's not in the search path...)

Compiling something on Linux is a piece of cake, even with dependencies, compared to Windows.

In Linux, the dependencies are just apt/dnf/yum away. In Windows, you have to build them, including their dependencies. There is no ./configure, no cmake config, it either has VS solution file (if you are lucky, it will even work with your version), or not. If you have the dependency library somewhere, you have to edit that project file tell the VS manually where it is. If you weren't lucky with an existing sln file, it's time to make your own.

Reading README to learn about dependencies and running configure with some flags is fine, compared to that.

Windows has cmake...

The point I was trying to make, that it will not help much. Most packages you are going to build do not support it yet.

Give me a couple of examples? Python is tied to an older Visual Studio normally. VS12 was different for reasons I can't remember but anything from VS13 onwards (for desktop) should build fine.

Try compiling SciPy from source using Microsoft dev tools. Or libgmp, the standard library for arbitrary precision integer arithmetic.

That's easy. For an extra challenge, try python-mapnik (libgmp is just one of the dependencies).

Anything that depends on both boost and gdal is bound to be pain. I once spent 22 hours getting a build of GDAL on FreeBSD with the drivers I needed.

Easy how? Otherwise the scipy maintainers would be doing it.

Relatively easy. I gave you an example, that has several dozens of dependencies, with several different build systems, of which not all of them support building with VS.

And that's targeting py3. For py2, you would need to build with VS2008, which some packages flat out refuse (for example, icu wants at least VS2010).

How many of them don't support MSVC due to requiring features that MSVC can't handle (like inline assembly or Fortran), vs not wanting to deal with build system contortions?

Honestly, I have no idea about the current status. Last time I tried, it was some two years ago and it was a major PITA. Since then, when I need newer versions, I just use either Linux or Mac.

I'm going to have to pretty much instantly admit defeat with SciPy: https://github.com/scipy/scipy/issues/5461#issuecomment-2871...

That issue is much more complicated than what most FOSS projects deal with.

I agree with you, building a lot of non-Windows stuff on Windows sucks. It's getting better, though.

With libgmp, it looks like you should use http://www.mpir.org/ but I don't know how this works with programs that expect gmp.

> That issue is much more complicated than what most FOSS projects deal with.

R or Julia would have the exact same problems if they cared at all about MSVC.

> I agree with you, building a lot of non-Windows stuff on Windows sucks. It's getting better, though.

I actually didn't say that at all. It's the Microsoft dev tools that suck. GCC works fine.

Reply on news.ycombinator.com