[zeromq-dev] Building on Windows
sustrik at fastmq.com
Sun Jan 4 00:29:42 CET 2009
Michael Greene wrote:
> Martin, and all,
>> Currently, there are 3 build systems in 0MQ because of Win32: MSVC
>> project, CMake and MinGW. We cannot maintain all three of them
>> Maintaining all 3 of them would be too much work with too little added
>> value for us. Thus, we would like to choose one to maintain.
> Is this really the breakdown? I think it is closer to this:
> 1) Autotools can build on Cygwin on Windows using GCC and optionally MinGW.
> 2) MSVC can build on vanilla Window using itself.
> 3) CMake can build using either Cygwin or Vanilla windows, generating
> makefiles or project files for either environment. The actual
> builders would be MinGW / MSVC.
> I think the options are either:
> * Only (1), requiring a dependency on Cygwin/MinGW to develop on Windows
> * (1) and (2), requiring maintenance of two separate build environments
> * (3), off-loading the maintenance of the two environments to an
> external project, but adding a dependency on that project.
What's (3)? You mean that 0MQ itself would come without a build system?
>> 2. Ideally, there should be only one build system which would mean that
>> MSVC proj is not an option as it doesn't work for non-Windows systems.
> This is true in the ideal case. However, unfortunately I don't know
> of a many-language project for which this works. Consider the case of
> (eventual) Ruby and .NET libraries. Ruby extensions explicitly cannot
> be compiled on Visual C++ 2008. .NET libraries must be compiled using
> Visual Studio or Mono.
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 :(
>> 3. Windows developers may be have little experience with anything aside
>> MSVC and say MinGW may be considered to be an entry barrier to high to
> I have seen this to be true on Thrift, a project that is incubating at
> Apache. Frequently, new users/developers there complain about the
> difficulty setting up a build environment on Windows as it does not
> compile under Visual C++. There are two reasons I think this might be
> less of a hindrance for 0MQ:
> * Releases are more frequent for 0MQ, and you suggest distribution of
> Windows binaries will be done in the future. Thrift is currently not
> producing binaries, and I think many of the complaints on the Thrift
> mailing lists are from "users" more than "contributors."
> * If CMake can in fact generate MSVC project files the casual Windows
> contributor would probably be satisfied. I am unfamiliar with CMake.
Actually, it would be nice to provide binary packages (msi, rpm, deb
etc.) for all the supported systems in the future. That way the user
won't have to worry about the build system. Only we - the developers -
would be affected by the issue.
>> 4. There may be performance difference between MSVC and gcc (MinGW) build.
> I have seen this to be the case, but would personally be willing to
> put up with the performance penalty on a build if there were logical
> reasons. With other projects the difference has been something like
> 2x-3x slower with MinGW.
> The performance difference of the resulting binaries would have to be
> measured with 0MQ. It can go both ways.
As 0MQ is heavily focused on performance, reducing the latency 2x-3x
would make MSVC the obvious choice for producing binaries to distribute.
Let's do actual measurement of the impact...
>> 5. MinGW may require additional dependencies on runtime (is it so?)
> This does not have to be the case, no. MinGW running under Cygwin
> must be told via the -mno-cygwin flag to cross-compile and not depend
> on Cygwin, but that is easy to setup.
More information about the zeromq-dev