Why is compiling on Windows such a nightmare?
I talked with some of the developers over at Microsoft about a month ago at an android event they hosted (ironic right?) specifically about some of the missing features in windows. My biggest gripes were command line based, for instance I wish it was possible for vim to be better integration with the default cli, and I wish we had a capable compiler bundled with Windows. They were actually super open to ideas, I think (at least from their end) it just hasn't been a priority because the folks who decide where to head next in the past have spent less time thinking about developers. That is changing for Microsoft. The event I attended was a direct example of that.
There are obviously some technical holdups, but I think the biggest holdup has been the status quo.
Recently when building an open source library I've been using msys and have had very very few problems- the only problems I've had have been related to me untar/gz ing without symbols.
There are obviously some technical holdups, but I think the biggest holdup has been the status quo.
Recently when building an open source library I've been using msys and have had very very few problems- the only problems I've had have been related to me untar/gz ing without symbols.
Yeah, the new CMD shell in Windows 10 is definitely a sign of good things to come, and the fact that they bundle support for C++ on Android in Visual Studio 2015 definitely shows they want developers to use their platform. It's just a shame that so much existing code out there doesn't work very well on Windows.
I'd be surprised if they were actually open to the idea of an integrated compiler included by default with Windows, it would be far more trouble than it's worth IMHO. Deployment time configuration settings are meant to be handled by the M$ installer package. If you have a known run-time version dependency you're supposed to use Windows SxS, not static linkage. I feel like only a small percentage of people would use it and an even smaller number of vendors would support it vs. the complaints and support issue requests that they would get from people like me who would have to remove it or lock it down everytime I deploy a machine or an image, but potentially still keep it available because 'X' thought it was a cool idea. I guess as long as they didn't do something incredibly stupid like sign the executable it wouldn't be too painful to manage, but it would be a potential gaping security hole.
Including a compiler with Windows would be pointless. It's standard practice in the Linux universe because of lack of binary compatibility between distros. In Windows you can simply make a Win32 executable that installs the appropriate executable for the machine (e.g. an x64 binary, an x86 binary with bell and whistles, or a basic x86 binary).
It makes as much sense for Android phones to come with GCC.
(No way, right? Please tell me they don't...)
It makes as much sense for Android phones to come with GCC.
(No way, right? Please tell me they don't...)
I didn't read the rest of the forum thread but...
From my experience, it's because people tend to rely on system libraries rather than including libraries within the tree. Whenever compilation happens on Windows, there is no system library tree to depend on so something has to be done about this where as on Linux, you sort of just assume they're there.
CMake is the only one currently that kind of eases this by automatically finding the pathing for Unix systems and Mac if possible and letting Windows users specify a path explicitly on where the libraries and headers are.
In proprietary projects, there's a tendency to just include any library needed within the project tree. This is convenient when compiling but is hard on the build system and requires much more maintenance.
From my experience, it's because people tend to rely on system libraries rather than including libraries within the tree. Whenever compilation happens on Windows, there is no system library tree to depend on so something has to be done about this where as on Linux, you sort of just assume they're there.
CMake is the only one currently that kind of eases this by automatically finding the pathing for Unix systems and Mac if possible and letting Windows users specify a path explicitly on where the libraries and headers are.
In proprietary projects, there's a tendency to just include any library needed within the project tree. This is convenient when compiling but is hard on the build system and requires much more maintenance.
I will also add that there's been quite a few projects that have the opposite problem... where things don't build on Linux but will build on Windows because Windows is a more tested environment.
Usually, this is mildly easy to fix both ways and contributing small fixes to a build system for a particular project can go a long way.
Usually, this is mildly easy to fix both ways and contributing small fixes to a build system for a particular project can go a long way.
In my experience, when it's hard to compile something that is supposed to be cross platform for windows, it's usually because there are lists of dependencies with version requirements. Someone usually has made binaries of all of the dependencies for some old version, but then things get updated and those become obsolete. Because Windows is only intended to be supported, and not the development environment, someone has to go out of their way, outside of the development environment to port and re-port and re-port as the software goes from version to version. And because the lists of dependencies that also need to be re-ported first can be large, people get so far behind keeping up with this never-ending chore, that Windows support becomes lost completely.
Last edited on
@htirwin: I ran into that issue with SFML once. SFML includes pre-built dependencies for Windows, but the particular combination of compilers I was using was incompatible with all of them, so I had to start compiling them all myself. However, that turned out to be a nightmare due to the helios effect - the dependencies usually required that you manually configure them, and at the time I had no idea that was even something I needed to do.
At least biicode is trying to fix the C++ dependency nightmare by using CMake as a package manager, but it still requires that a library be modified to use biicode.
At least biicode is trying to fix the C++ dependency nightmare by using CMake as a package manager, but it still requires that a library be modified to use biicode.
Last edited on
I know the pain that is trying to get anything to work with Windows. I spent a very good time (days, literal days) trying to get Codeblocks to link a library. No dice. I spent several hours messing around with Linux shells trying to get the Epoxy library to build, no dice. Found a fork of it that included a CMake file, and that one built fine. At least, until I tried to link it, at which point I realized that over years of trying to learn openGL and whatever else, I never successfully got Codeblocks to ever link a library.
So, I gave up on trying to use Codeblocks and went with installing Arch Linux. I then missed a step and wrecked my main drive (forgot to actually create a config file for GRUB, so even though it was installed, it didn't actually know how to boot). Spent the rest of the day downloading 107 updates for Windows because though I had the foresight to make a system repair disk, I didn't have the foresight to make a system image more recent than January.
As for CMake, yeah, it's quite wonderful. I ended up finding a different library (glbinding) that did include a default CMake file, and that built fine. Still can't link it, obviously, but at least it builds without having to use some Linux shell or other nonsense.
I'm also willing to bet that my perpetual issues with git are partly due to its incompatibility with Windows (projects will work perfectly for a week before never working again bar a system image restoration- even reinstalling everything doesn't fix it).
So, I gave up on trying to use Codeblocks and went with installing Arch Linux. I then missed a step and wrecked my main drive (forgot to actually create a config file for GRUB, so even though it was installed, it didn't actually know how to boot). Spent the rest of the day downloading 107 updates for Windows because though I had the foresight to make a system repair disk, I didn't have the foresight to make a system image more recent than January.
As for CMake, yeah, it's quite wonderful. I ended up finding a different library (glbinding) that did include a default CMake file, and that built fine. Still can't link it, obviously, but at least it builds without having to use some Linux shell or other nonsense.
I'm also willing to bet that my perpetual issues with git are partly due to its incompatibility with Windows (projects will work perfectly for a week before never working again bar a system image restoration- even reinstalling everything doesn't fix it).
| I never successfully got Codeblocks to ever link a library. |
C::B is annoying in that when you go to link a library it has three separate scopes: project, debug and release. I constantly make the mistake of linking a lib to the project scope, which doesn't do anything, and not to the debug or release versions which are actually what get compiled. Do you think that's the issue that you're having?
@Ispil - ouch.
If you use CMake in your own project as well, you can just have it do all the dirty work for you. It can generate project files for most IDEs, so you should never need to touch project settings to adjust linkage - CMake will just do it all for you, all the while you get to use your favorite IDE.
Which variant of git do you use? I used to use the version that comes bundled with GitHub for Windows (now called GitHub Desktop), but it's super outdated so I now use the version that comes bundled with nuwen MinGW (and I have it set as my shell inside of GitHub Desktop, so I never have to enter any credentials).
If you use CMake in your own project as well, you can just have it do all the dirty work for you. It can generate project files for most IDEs, so you should never need to touch project settings to adjust linkage - CMake will just do it all for you, all the while you get to use your favorite IDE.
Which variant of git do you use? I used to use the version that comes bundled with GitHub for Windows (now called GitHub Desktop), but it's super outdated so I now use the version that comes bundled with nuwen MinGW (and I have it set as my shell inside of GitHub Desktop, so I never have to enter any credentials).
Here's an example I ran into recently. I was trying to build FreeType shared libraries using CMake and Visual Studio, but it's outright forbidden:
This is completely false information, because there is a StackOverflow answer explaining how to do it and it's very simple:
http://stackoverflow.com/a/7387618/1959975
!!?!?
if (WIN32 AND NOT MINGW AND BUILD_SHARED_LIBS) message(FATAL_ERROR "Building shared libraries on Windows needs MinGW") endif () |
http://stackoverflow.com/a/7387618/1959975
!!?!?
Weird, but why would you use cmake when there's a solution included with the sources?
| helios wrote: |
|---|
| Weird, but why would you use cmake when there's a solution included with the sources? |
-DBUILD_SHARED_LIBS=ON to the command line. Basically it is not possible to automate building shared libraries on Windows without CMake in this case, except they explicitly forbid it.
Last edited on
The instructions described in that SO answer can be trivially automated. The simplest solution is to patch the files in question prior to compilation.
Yeah, but now you have to maintain patches as they change things...it's like your own miniature fork. Anything more than just running cmake is not what I would call 'trivial'. To each their own, I guess.
Last edited on
You can get a bit more sophisticated, of course. Changing the VS project file is fairly easy, since it's just an XML. ftoption.h is just a configuration file with a bunch of #defines.
That's also not a bad idea. It's what I'm doing with Crypto++ so I can easily include it in the solution. The trick is to keep the changes simple to be able to merge from upstream without conflicts.
I find your naivete adorable.
As much as I agree that it would be nice if things worked like this, they just don't. If you want to waste time screwing around with build systems until you get everything neat und tidy, that's your prerogative. I prefer to work in the projects I actually want to work in.
Or you can just make your own build system.
https://xkcd.com/927/
| it's like your own miniature fork. |
| Anything more than just running cmake is not what I would call 'trivial'. |
As much as I agree that it would be nice if things worked like this, they just don't. If you want to waste time screwing around with build systems until you get everything neat und tidy, that's your prerogative. I prefer to work in the projects I actually want to work in.
Or you can just make your own build system.
https://xkcd.com/927/
Just out of curiosity- say that I'm writing a rather complicated program on Linux that includes a lot of shared libraries and the like. How would I set that up so I can get it to cross-compile for Windows and properly install it on Windows? For one, does it require me to fish out all of the libraries that I normally have in /usr/lib and dump them into a folder where my code lives?
I mean, all I want to do is write code on Linux and test it on Windows without having to make all the libraries static.
I mean, all I want to do is write code on Linux and test it on Windows without having to make all the libraries static.
Do you mean during cross-compile time or during run time? I think cross-compilers have like their own /usr/lib analogues. At least that's how the Android NDK worked on Windows.
The problem is that, say I write a piece of code that would run fine on Linux that uses some library like GLFW. Assuming I don't static-link GLFW, how do I compile that on Linux in a way that would allow the code to run on Windows?