search

squeevee / Addle

Pretty little drawing application and image utility
MIT License
3 stars 1 forks source link

Windows build #7

Closed squeevee closed 4 years ago

squeevee commented 4 years ago

Build Addle for Windows with MinGW-w64 and MSVC.

Bonus points for attempting to build Addle for Win32.

squeevee commented 4 years ago

After some deliberation, I have decided that Addle will only support MinGW-w64 based builds on Windows. Supporting MSVC adds clutter to the source code, constrains the libraries Addle can use on Windows, and represents a general vague compatibility hazard where all our other target platforms are POSIX. These would be perfectly livable (lots of projects put up with it), but frankly I don't think MSVC support would add that much value to Addle.

MinGW-w64 works quite well and definitely simplifies this leg of cross-platform support. Meanwhile, Addle isn't a library or utility that necessitates ABI compatibility, and the requirement of Qt is already quite large enough that I don't find the requirement of a (free and open source) compiler and toolchain to be that significant of an increase to our build burden.

I still intend for Addle to support plugins compiled with MSVC.

Clang exposes some interesting MSVC compatibility features that could represent some kind of compromise solution and/or means of using Visual Studio to develop and debug Addle.

squeevee commented 4 years ago

I am reversing this decision in light of three important pieces of information:

  1. __declspec( dllexport ) and __declspec( dllimport ) specifiers are actually not so much about MSVC as they are about Windows DLLs -- which stands to reason, given the "DLL" in the names. While MinGW-w64/GCC is able to link symbols declared without these specifiers, they will not be relocated during runtime, meaning that the "same" symbols will have different addresses from the perspectives of different libraries. That is a problem when, for example, calling QObject::connect in one library, using a pointer to a member function defined in another library.
  2. If a library contains __declspec( dllexport ) directives, MinGW-w64/GCC will link it using MSVC-style rules instead of the default Linux-style rules, meaning that GCC will produce similar linker errors for missing export specifiers.
  3. Classes containing only pure-virtual methods do not need to be exported.

These import/export specifiers were a big reason why I was so reluctant to support MSVC, since GCC "worked" without them and MSVC didn't. But note 1 shows us avoiding them is much more of a "compatibility hazard" than using them. Notes 2 and 3 show us that they will not be too difficult to maintain as their use can be checked from Linux and there will not be nearly as many of them as I expected.

MSVC still requires small adjustments to be happy, but at this point they're basically trivial. Meanwhile, MSVC is the most popular and well-supported compiler for native Windows binaries, so I might as well support it in the spirit of making Addle more accessible to the developer community and the tools that are available. Plus, being natively supported makes it possibly advantageous for performance or debugging on Windows.

After 999603e86789397d1d03ebaf771ca7c98767e5e7 I was able to successfully build and run the dev_1 branch using MSVC.