[nanomsg] Re: Release packaging and build systems

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Thu, 25 Jul 2013 09:43:58 +0200

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



Other related posts: