[zeromq-dev] Building on Windows

[Martin Sustrik]

Pieter,

Happy new year to you!

Pieter Hintjens wrote:
> On Sun, Jan 4, 2009 at 12:29 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> 
>> Fair enough. .NET extension is already under development - we won't be
>> able to build it without MSVC. Damn, why does MSFT have to make things
>> that complex :(
> 
> It's called lock-in.  It would be best IMO if 0MQ was as independent
> as possible of build systems and autoconf, so that it could be built
> using any tool.  For example I'd like to try making a boom package
> (boom is the iMatix build tool) but the sources seem tied to
> autocconf/make (am I wrong?)

Actually, no. The only relevant thing that's done by autotools is to 
generate libzmq/zmq/plaform.hpp file which contains a single macro 
definition specifying the OS you are building 0MQ for. This way:

#define ZMQ_HAVE_LINUX 1

Of course, we can require the macro to be passed on compiler's command 
line to make it easier for alternative build systems.

> If you do use MSVC to build the .NET extension, you should not force
> that on the rest of the product.

I am thinking of separating individual language extensions (Java, 
Python, C, .NET) into separate projects. Each of them has special build 
requirements (paths, env vars, etc.) anyway...

> You can usually detect and handle compiler differences inside the
> source code, though obviously you will need to build project files and
> build scripts properly.  Some kind of manifest (such as the XML
> project.pdl files we use in iMatix) would make it possible for random
> people to make random build scripts for the project.
> 
> So at that stage you can delegate this issue to the community, which
> is really what you want to do.

Still, we want to release new versions ourselves, if only to have single 
authority for assigning version numbers. To that end we have to have 
single toolchain to create the packages (although N alternative build 
systems may happily coexist in the project). So my question was about 
this "vanilla" toolchain rather than about build systems in general.

Martin