[zeromq-dev] [PATCH] MSVC10 project files

Stuart Webster sw_webster at hotmail.com
Thu Nov 24 23:13:48 CET 2011

I think those are practical suggestions. Mikko raised the point that we 
shouldn't drop support for VC9 in a point release of 0MQ 2.1 for reasons 
of backwards compatibility. I'm not sure whether he was referring to 
compatibility with other components or other toolsets. Could you please 
elaborate, Mikko? I can't see how backwards compatibility is a 
significant issue.

Firstly, libzmq.dll only exports C functions, so the fact that it uses 
the VC10 CRT internally is of no consequence to host applications, 
regardless of which version(s) of the CRT their other components link 
to. In any case, anyone who wishes to continue to link libzmq to the VC9 
CRT can simply change the PlatformToolset property of the project to 
"v90" and Visual Studio 2010 will compile that project with the VC9 
compiler and libraries.

Secondly, anyone can build VC10 projects using the free Windows 7 SDK 
independently of any editions of Visual Studio that they currently have 
installed. They could even use VC10 Express (also free) to build the 
32-bit project configurations, which are the only configurations 
provided by the current VC9 projects.

Maintenance of autotools + MSVC2010 should require no more effort than 
maintenance of autotools + MSVC2008, which is the responsibility that 
Mikko and Martin have now. The upside is that it makes 0MQ more 
accessible to those Microsoft developers who are using the current 
version of Visual Studio, which given that it has been out for a couple 
of years now probably comprises a significant proportion of them.

Going forward, migration to cmake + MSVC10 sounds like a longer term 
project (perhaps for 0MQ/3.0?) with the potential end goal of a complete 
transition to cmake for all platforms. Is that acceptable to everyone?


> just to play a little with this thought, what about this:
> Official support for CMake and MSVC2010. People needing to build with
> VC08 would then have to use the CMake structure, but it still is
> supported somehow. You'd get support for Eclipse, KDevelop, ... for free
> within the CMake structure.
> just my 2c,
> Andreas

On 24/11/2011 09:42, Martin Sustrik wrote:
> Hi Stuart,
> Let me summarise.
> The problem we are solving is that MSVC2008 project doesn't convert 
> seamlessly into MSVC2010 project (some directory setting is broken in 
> the provess IIRC).
> The solution so far seems to be to discard the MSVC build system, 
> replace it by CMake build system, then bundle CMake with libzmq and 
> make the whole bunch work together.
> My question thus is: Isn't there an easier way to solve the problem? 
> Like, say, abandoning MSVC2008 and requiring MSVC2010 to build libzmq?
> Martin
> On 11/23/2011 02:27 AM, Stuart Webster wrote:
>> There's good news and bad news.
>> First, the good news is that the implicit dependency that Andreas
>> mentioned can be avoided by specifying "set(CMAKE_SUPPRESS_REGENERATION
>> 1)" in CMakeLists.txt. The default behaviour is for cmake to add a
>> pre-build step that will regenerate Visual Studio projects if it detects
>> any changes in the CMakeFiles subdirectory of their build folder, but I
>> verified that this step was absent from the libzmq project generated
>> from Steve-o's CMakeList.txt after adding this flag.
>> The bad news is that this deployment model isn't officially supported by
>> the cmake developers, who caution against doing this. They actually
>> recommend bundling cmake with your CMakeList.txt file(s) instead:
>>       http://www.mail-archive.com/cmake@cmake.org/msg16634.html
>>       http://www.mail-archive.com/cmake@cmake.org/msg12692.html
>> Cross-generating MSVC project files from other operating systems is not
>> possible, so you would need to generate them on a Windows build machine:
>>       http://www.mail-archive.com/cmake@cmake.org/msg12736.html
>> One thing to be aware of is that the current release (2.8.6) has a bug
>> in which it always specifies absolute paths of source files in generated
>> MSVC project files, even if you specify relative paths
>> ("set(CMAKE_USE_RELATIVE_PATHS 1)") in your make file. That means that
>> we would be restricted to using an unsupported older release:
>>       http://www.mail-archive.com/cmake@cmake.org/msg39143.html
>> Lastly, generating projects that target both 32- and 64-bit platforms is
>> not possible either, so you would have to generate a separate project /
>> solution for 64-bit builds:
>>       http://www.mail-archive.com/cmake@cmake.org/msg38787.html
>> I was planning to extend the project in my original patch to support the
>> Intel compiler as well (it can use the unpatched C99 openpgm code and
>> generates faster binaries, but that's a topic for another day). It would
>> be unfeasible to provide that support if it meant doubling the number of
>> solutions shipped with the source code, but it looks like it would be
>> easy enough to add to the CMakeLists.txt file.
>> In summary, it is possible to use cmake to generate MSVC project files
>> that have no dependencies on cmake itself. However, that's not what it
>> is designed to do, we would have to use an old version to do so on a
>> Windows build machine and the generated project (I presume there would
>> be only one) would only support 32-bit build targets. Couple that with
>> the fact that providing generated project files firmly places the
>> responsibility for those files with the zeromq community and I can see
>> why the cmake guys recommend just bundling cmake with your project.
>> If we went down that road we would need to make sure that we bundle a
>> version of cmake that does not suffer from the relative path bug. I
>> think Martin was correct the other day when he suggested that the
>> typical use case at most Windows shops will be for the guy who
>> downloaded 0MQ to build the library on his workstation and then import
>> the source into the relevant corporate repository. If the project files
>> that he generated contained absolute paths, the next person to try to
>> build 0MQ will likely get a bunch of errors, which creates a very poor
>> first impression.
>> Stuart

More information about the zeromq-dev mailing list