4 ms·

Regarding MSBuild, the biggest problem I had with it is that if you built projects with Visual Studio, using most of the standard tooling for adding references

Regarding MSBuild, the biggest problem I had with it is that if you built projects with Visual Studio, using most of the standard tooling for adding references and dependencies, you'd often be left with a project that built fine with Visual Studio, but had errors with MSBuild. The reverse, incidentally, was usually okay. If you could build it with MSBuild, it usually worked in Visual Studio unless you used a lot of custom tasks to move files around. I personally believe the fact that Visual Studio is all but required to build on Windows is one of the single most common reasons you don't see much OSS that is Windows friendly aside from those that are Java based.

shadowfox 15y ago
> I personally believe the fact that Visual Studio is all but required to build on Windows is one of the single most common reasons you don't see much OSS that is Windows friendly aside from those that are Java based You don't necessarily have to use VS to develop on windows. Mingw works quite well for a lot of cross-platform things and it is gcc and works with gnu make. My experience with porting OSS between Windows and Linux (both ways) has been that very few developers take the time out to encapsulate OS specific routines in a way that allows easy(ier) porting. You end up having to #ifdef a bunch of stuff in order to avoid a full rewrite. This is not a claim that porting is trivial. You do run in to subtle and not-so-subtle issues anyway. But careful design can help a lot. Then again this requires that you start out with portability in mind.
- helmut_hed 15y ago
  I like to make multi-platform code, and I do it with CMake, Boost, and Qt. My target platforms are Linux/g++ and Visual Studio (not mingw). It usually works OK after a little tweaking, but you have to maintain discipline on whichever system you're coding on, and not use nonportable pragmas etc.
Shorel 15y ago
I used to build wxWidgets and all my personally made Windows Software using mingw and gcc. Sadly, gcc is far, far slower than other compilers in windows (and once or twice I have found some compiler errors in gcc). I also used Digital Mars for the same, but DMC sometimes fails with big builds. I use Visual Studio now because I'm using DirectX and I just want something that works out of the box.

shadowfox 15y ago

> I personally believe the fact that Visual Studio is all but required to build on Windows is one of the single most common reasons you don't see much OSS that is Windows friendly aside from those that are Java based You don't necessarily have to use VS to develop on windows. Mingw works quite well for a lot of cross-platform things and it is gcc and works with gnu make. My experience with porting OSS between Windows and Linux (both ways) has been that very few developers take the time out to encapsulate OS specific routines in a way that allows easy(ier) porting. You end up having to #ifdef a bunch of stuff in order to avoid a full rewrite. This is not a claim that porting is trivial. You do run in to subtle and not-so-subtle issues anyway. But careful design can help a lot. Then again this requires that you start out with portability in mind.

helmut_hed 15y ago
I like to make multi-platform code, and I do it with CMake, Boost, and Qt. My target platforms are Linux/g++ and Visual Studio (not mingw). It usually works OK after a little tweaking, but you have to maintain discipline on whichever system you're coding on, and not use nonportable pragmas etc.

Shorel 15y ago

I used to build wxWidgets and all my personally made Windows Software using mingw and gcc. Sadly, gcc is far, far slower than other compilers in windows (and once or twice I have found some compiler errors in gcc). I also used Digital Mars for the same, but DMC sometimes fails with big builds. I use Visual Studio now because I'm using DirectX and I just want something that works out of the box.