Hi all,The question here seems to boil down to how far we are willing to go to accomodate Windows nanomsg developers and not force them to learn new and unfamiliar toolchains.
COMMENT: Please note that we are not speaking about *users* of nanomsg on Windows! They should be OK with binary packages.
A.) The furthest we can possibly go is maintaining MSVC solution files as we did with ZeroMQ. The problem here is twofold. First, MSVC solutions are managed via GUI :( Second, every version of MSVC has different solution file format, so we would have to maintain multiple versions of the solution files.
B.) If that seems excessive we can provide a way to *generate* MSVC solution files. That way the Windows developer can learn just the generation part of the toolchain and continue with MSVC IDE as normal.
C.) We can be even less forthcoming and drop MSVC support entirely. In such case Windows nanomsg developers would have to learn MinGW toolchain. The upside would be maintaining just a single build system.
Thoughts anyone? Martin On 24/07/13 14:59, luca barbato wrote:
On Wed, Jul 24, 2013 at 2:26 PM, Gonzalo Diethelm <gonzalo.diethelm@xxxxxxxxx> wrote:If I had to choose between cross-compilation support and Windows support, I would opt for Windows support. FWIW.The problem is defining what's Windows support. - Providing headers and binaries so msvc users can just drop them in their project and build their programs? - Providing a solution in release 7z so they can build it on msvc? - Providing a way to cross compile to windows as VLC and many other projects do? For my specific usages not having a way to easily cross compile (including the windows target by the mean of mingw-64) would be a problem since what I have in mind with nanomsg would enjoy that (since all the other bits use the same way). For a contributor learning how to use cmake or autotools, if not necessary, it is at least warmly welcome. As you can see both build systems are made to be extremely straightforward, the autotools one is literally 2 files to edit at most, so even keeping both in sync shouldn't be a huge burden. lu